Future...

[Kristian Nielsen]

Hi Emmanuel,

Ok, I am now back from vacation, so here are some comments on the points
you asked about on July 6.

> As I told you last time you passed at the ILL, I have applied to a
> permanent position at the ILL in the Computer Simulation group.
> And that's OK !

Once again congratulations with your new positions, I hope this will
mean that you will play an even more active role in McStas development.

Several of your points touch upon a subtle but important detail in the
way parameters are passed to components from the instrument
definitions. This currently works (in the generated C code) using C
macros (#define). Because of this, many of the usual problems with C
macros apply.

Using C macros was the easiest solution, but I kind of regret it now. It
would have been better to use proper variables. However, in order to use
real C variables, McStas will need to understand the C types of
component parameters. Most of these are "double" of course, but they can
also be strings, arrays, structures, function pointers, etc. It is not
inherently difficult to make this extension in McStas, but it is some
work because of the complexity of C.

[Hm. Actually, McStas already knows the type of "SETTING PARAMETERS",
since they are always "double"... ]

In any case, the desirable features that you mention would be rather
easy to implement once McStas was extended to use real C variables for
component parameters instead of macros. You might want to take a closer
look at the C code that McStas generates to see the details.

> 1) would it be possible to put, in the TRACE section, some bits of C
> code, e.g.:

> COMPONENT ... blahblah = bouh(a=my_local_variable)

I think I see what you want. It is difficult in the current design
because of the use of C macros for parameters, but by using proper C
variables it should be simple.

> 2) would it be possible, for numerical component parameters, to indicate
> (in TRACE) an expression instead of a single variables name, e.g.:
> 
> COMPONENT ... blahblah = bouh(a=my_local_variable*2)

Again, not so good when using C macros (the expression would be recomputed
for each neutron!), but simple with real C variables. Of course, it
would be necessary to write a parser for C expressions, which is not
completely trivial.

> 3) about neutron polarisation, I'm lost.

I think we discussed this previously? Basically, the s1 and s2 STATE
PARAMETERS are NOT used in McStas, period. The are just dummy names and
have nothing to do with polarisation or anything else. For example, they
are not transformed when components are ROTATED. Polarisation should
always use POLARISATION PARAMETERS(sx,sy,sz).

However, I see your point about the Monitor_nD. If you were to put in
polarisation, non-polarisation instruments would create a bunch of
warnings. I think we should just remove the warning and use POLARISATION
PARAMETERS. No components need to be changed, those that do not use
POLARISATION PARAMETERS will just pass on (sx,sy,sz) unchanged.

> 5) Would it be possible to define a macro
> PROTECT name
> that would append the current component/instrument name root and
> generate
> #define name component+name
> just as component and instrument parameters

I think this is exactly what is achieved by including the name in the
list of OUTPUT PARAMETERS.



I should tell you that there is going to be a change of things here at
Risoe concerning McStas. Management decisions two years ago have forced
me to the opposite change of work that you do now, from scientific
computing towards physics. I have decided that this is not what I want,
and I am therefore leaving my job at Risoe, and hence McStas. The plan
is that someone else at Risoe will take over, but nothing is decided
yet. In any case, you have a lot of in-depth knowledge and interest
concerning McStas, and with the intense simulation activity at the ILL I
think it would be very good if you and the ILL got more involved in the
development of McStas itself.

 - Kristian.