Component library

[Per-Olof Åstrand]

Hi,

Rob Kreuger wrote:

> Hello,
>
> concerning the way the component libraries are maintained at Riso and ILL,
> I would like to make the following remarks:
>
> 1) There is no need to distinguish between official Mcstas and unofficial
> user components. Just define the "origin" of a component by the author,
> which for components made by Riso can be called "Risoe" or "Mcstas". Then
> people know that the component is from the official Mcstas team. This
> tells enough about the origin.

The distinction is important for me as a maintainer since I need to make sure
that I have the most recent versions of the components included in a McStas
release. If it is only an issue for me, however, if a component is official
or not then I think we should remove the components from the official release
of McStas. Today I anyway regard a component as belonging to the author
regardless of it is in the McStas release or only available in the component
library, and I expect the author to make necessary changes and notify me if
it is to be included somewhere.

A suggestion is thus that components are only administrated by the McDoc tool
and they are put there as provided by the author. If someone suspects a
problem with a component, it is notified on the email list and I will put it
in "News"/"Known Problems" on the web. If someone has suggestions for
modifications in a component, they should be communicated to the author which
then supplies the updated version to the McDoc maintainer. Further comments
are very welcome!

>
> 2) Different versions of the components should remain available on the
> webpage. So a version number is the second part identifying the module.
>
> Why do I want to have old versions available?  Because if someone runs a
> simulation now, with the actual version of the components, he get certain
> results. If he is going to run it two years later, with components with
> updated versions, with the same instrument file he might get different
> results! That is very annoying and much time will be spent to find out
> what happened. So it is important that he can run the same instrument
> file, but with old components to make sure that the difference is in the
> upgrading of components and not a (forgotten) modification of his
> instrument file. Reproducability of simulation runs is very important on
> the long term.
>
> In order for this to make sense, people have to know with which version of
> components they have run their simulation. therefor I would propose to
> include in the Mcstas output file to write which components and which
> versions have been used in the simulation.

This is a very important point.

For the components developed by Kristian, all previous versions may be
generated since we use a revision control system (RCS). The same is true for
components by others sent to me, which I also put into RCS.

I will put this on the to-do-list: a library available on the web with all
versions of a component (that become available to me) and a print statement
in the simulation program providing the versions of the components.

> 3)One could also separate the Mcstas kernel from the component library.
> People who want to use Mcstas just get the latest kernel and the
> component library with the most recent version of th components. And at
> any time they can get more recent or older component version by just
> downloading them from the webpage.
> And of course for a new release of Mcstas it might be said that it only
> works with the latest version of components.

This is more or less in line with my response to the previous points. I think
that a component written for a 1.x version should run in all 1.x versions of
Mc. If backwards compability is not guaranteed, we have to announce a version
2.0. If we are strict about this policy, it would make life easier for users
writing components.

> cheers,
> Rob Kreuger
>

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