shared library directory

[rs028]

As it is now, the build script always creates mechanism.so in model/configuration. This makes the --shared-lib flag of the executable basically useless (although it still needs to be explicitly set if --model or --configuration are not set to the default values).

This is not a big issue, but it would make sense to

1. reintroduce the argument for the shared library in build.sh

OR

1. remove the --shared_lib flag (the easiest way would be to just hardcode it, like for reactionRates_dir)

[spco]

Unless I am misunderstanding, this is not quite right. build/build_atchem2.sh has a second optional argument which indicates the directory to place mechanism.f90 and mechanism.so in (as well as mechanism.species etc - this is also passed as the second argument to build/mech_converter.py. This defaults to model/configuration/, but can be anywhere. So I believe the first option above is already the case. --shared_lib then follows that case of defaulting to the same location.

[rs028]

Sorry, that was poorly phrased. What I meant is that there is no difference between the location of the shared library and that of the other mechanism.* files. The script takes 3 arguments. The second argument is the same for both the build/mech_converter.py and make sharedlib commands.

So, this is fine:

./atchem2 --configuration=project/config --shared_lib=project/config

but, this won't work:

./atchem2 --configuration=project/config --shared_lib=project/mech

Now the question is whether it makes sense to allow the shared library to be separated by the mechanism.* files or not. In the former case we might as well remove the --shared_lib switch from the executable, in the latter we need to add a separate argument in build.sh for the make sharedlib command.

PS: if we are reworking the build.sh script we might consider #416 as well.

[mixtli-c]

FWIW, it can cause some confusion when building AtChem for different projects following Figure 4.1 in the manual. If the shared_lib flag is not set, it throws a fortran error that is hard to parse by an inexperienced user (e.g. me)

[rs028]

Hi @mixtli-c thanks for your feedback. I agree that both the use of the executable flags and the instruction in the manual could be better. Any suggestion on how to be improve this is welcome :)