-
Notifications
You must be signed in to change notification settings - Fork 60
HOWTO: Modifying a McStas 2 component for use under McStas 3
For examples of converted components please compare the mcstas 3.1 components with their counterparts from mcstas 2.7.1
All DEFINITION parameters must be removed.
- normal double/int/numeric ones are no issue, they can be transferred to
SETTINGparameters without issues - Similarly, strings are a new supported type in
SETTINGparameters and can be transferred without issues - Pointers/lists should be handled with the new vector type. (
vector V={a,b,c,d))
The DECLARE section needs adjustments so that
- It only contains declarations without initialisation (init part goes in
INITIALIZE) - variables in the
DECLAREsection must be present with type on line by line, i.e.
DECLARE %{
double a,b;
%}
must become
DECLARE %{
double a;
double b;
%}
- If there are any functions in
DECLAREthese must be moved toSHARE. - If such functions are used in
TRACEthey, they will need a#pragma acc routine- if they are to be GPU-compatible - Any function that uses e.g.
rand01()inside must have a footprint that includes_class_particle* _particlefor forwarding RNG information
If the component is to be used on GPU and uses external libraries in TRACE, one must either
- Find a way to do the library-work in
INTIALIZEand/orFINALLY - Mark the component
NOACCin the header - which means that it will execute on CPU only
… and then there may be further work in TRACE to ensure that DECLARE-parameters are not used to store particle-derived information... A good way to ensure this is that results on CPU and GPU should be identical if run with the same seed.
If you still have issues converting your component, feel free to write us an issue (https://github.com/McStasMcXtrace/McCode/issues) or send [email protected] an email including the component in question plus a relevant test-instrument :)