About component version and origin

[Per-Olof Åstrand]

Hi,

Emmanuel Farhi wrote:

> Hello all of you,
>
> About the Gravity_guide (attached file):
> The 'G' constant should be a protected variable, to avoid conflicts
> with other macros:
> OUTPUT PARAMETERS (ww,hh,whalf,hhalf,lwhalf,lhhalf)
> ...
> double G;
> ...
> G=9.82;

I discussed it with Kim who is the author of the component and it has
been changed according to your suggestion. G should really be included
in McStas as a predefined constant but preferrably with another name.

> About the Bender:
> The Bender doc header is not valid. I here attach a full version.
>
> About version control for comp:
> I do not think the proposition of Per-Olof will solve the problems of
> indentifying what are the component versions and origin. At the end
> you would have only 'official updated' and 'unofficial' components,
> and this info would not be very useful !
> The best way would be to have a 'version' column in the McDoc
> automatic page (list of comps).
> Also, the column 'Help' is not very informative (except when you click
> on 'More...'. perhaps this 'More...' item could be moved to 'More
> (version number)'. If McStas is to be opened and shared by users, I
> think the real origin of the components should be displayed clearly,
> even when these comps are included in the official release. I like to
> know that the bender comes from Erlangen.
> When you put 'official release', just add also the McStas version it
> is associated to (modify headers to have this displayed).

Perhaps, we should remove all components from the official release of
McStas and only associate them with the author and lab, but I will
discuss it in more detail in my forthcoming response to Rob Kreuger. To
avoid misunderstandings, I did not mean that the geographic origin
should be removed, but instead moved to the "Authors" entry which then
would contain both the author and the lab. I am quite sure that using
the "Origin" for a geographic origin is a misconception of the original
intention.

>
> Comp update
> Also, perhaps it is the time, for version 1.4.1 to come, to update the
> POLARISATION PARAMETERS (sx, sy, sz) in every comp ? (I have not done
> that yet)

The support for the representation of spin as (sx,sy,sz) is on the top
of the list, apart from urgent matters that may appear on the mailing
list. If I remember correctly, it was agreed at the workshop in Jan.
that backwards compability should be guaranteed as far as possible which
means that a forthcoming version should allow both representations.

Now, you should not expect too much with respect to the speed of
developments. I am working on McStas 50% of my time, which I divide on a
weekly basis. One week at Risø and the next week at the University of
Copenhagen. When I am not at Risø I only respond to urgent emails,
whereas I work 100% with McStas when I am here. That means that I so far
had five full working weeks to learn McStas from scratch, which also
includes the workshop here at Risø, and I still spend most of the time
reading the source code to find out what is actually happening. Next
week is at PSI and then a week at University of Copenhagen, which means
that hopefully we will see some progress on polarization in the McStas
kernel the first week in April. That is the way it is and that is what
we have to live with.

I also think it is quite nice that we start to see a mailing list that
is alive!

Best regards,

Per-Olof Åstrand

--
Per-Olof Åstrand
Dept. of Chemistry, University of Copenhagen
and Materials Research Department, Risø National Laboratory
per-olof.aastrand at theory.ki.ku.dk or per-olof.aastrand at risoe.dk
http://www.ki.ku.dk and http://www.risoe.dk