whizard is hosted by Hepforge, IPPP Durham
close Warning: Error with navigation contributor "BrowserModule"

Opened 8 years ago

Closed 8 years ago

#819 closed task (fixed)

Support for OMega's UFO functionality

Reported by: kilian Owned by: ohl
Priority: P1 Milestone: v2.5.0
Component: interfaces Version: 2.4.0
Severity: normal Keywords:
Cc:

Description

The existing API for UFO models handled by O'Mega has to be supported by WHIZARD (and Sindarin). The necessary ingredients appear to be present now.

Change History (9)

comment:1 Changed 8 years ago by kilian

Related to #56 and #59.

comment:2 Changed 8 years ago by kilian

Priority: P2P1
Status: newassigned

Thorsten's UFO interface is already functional (some minor issues remaining); calling the interface works on the unit-test level. The main issue is proper treatment of the generated model (it appears as if the .mdl file has to be generated before the process is handled, actually already in the compile pass of Sindarin) ... otherwise the model variables cannot be recognized by Sindarin.

comment:3 Changed 8 years ago by kilian

Contrary to my previous statement, the syntax model = SM { ?ufo=true } won't work. Models have to be read on the first pass of the script, so they can provide their model variables to the interpreter. Variable values are not available in the first pass.

So, why not consider ufo as a scheme. (We can reasonably expect that the UFO format itself won't support schemes in the way we introduced this feature. Or we can allow for two model arguments.)

The syntax will thus be model = SM (ufo). Simple enough.

I'll have to take some precautions that the UFO-generated SM doesn't clash with the built-in SM. This is a danger for the test suite.

comment:4 Changed 8 years ago by Juergen Reuter

I actually like the new syntax <model> (ufo). However, does this mean that there always needs to be a model <model>.mdl be available inside WHIZARD? This would be a killer. If not, then why not use a different name for the tests like SM_UFO (ufo)? Or is it TO's UFO testfile that dictates this?

comment:5 Changed 8 years ago by kilian

UFO and non-UFO models should not know about each other, even if the names are identical. We could distinguish UFO models by a suffix in their name, but I think it's more future-proof if we don't do this. We don't know whether UFO will become standard when using Whizard, or not. So keep the user syntax simple.

Models in memory do know whether they are UFO or not.

I'm currently looking at the actual model files. I may have a different suffix {{{.ufo.mdl}} in the file name, but not in the model name. If the distinction is after the dot, no problem.

Version 0, edited 8 years ago by kilian (next)

comment:6 Changed 8 years ago by kilian

UFO handling works in the testsuite. Missing parts:

  • some problem with SM parameters in the test model
  • make installcheck doesn't work because the test model is not installed.
  • The working directory is not yet searched for user models.

comment:7 Changed 8 years ago by kilian

The directory issues are solved now. Last issue is numerical agreement.

For searching for the a UFO sources of a model, WHIZARD looks at

  1. the working directory. If model = Foo (ufo) is requested, the Python files have to reside in subdirectory Foo.
  2. the directory share/models/UFO, again inside subdirectory Foo.

The functional tests use the working directory.

comment:8 Changed 8 years ago by kilian

Owner: changed from kilian to ohl
Status: assignednew

The Whizard side of this is complete now; some validation still under way on the O'Mega side.

comment:9 Changed 8 years ago by Juergen Reuter

Resolution: fixed
Status: newclosed

This is finished now, and the UFO SM as well as SM-like models via UFO are completely supported. Completely general UFO models are deferred to #56 and #142.

Note: See TracTickets for help on using tickets.