[Discussion] Include support for additional SERPENT versions

[drewejohnson]

TL;DR: We should include support for additional versions of SERPENT. Other tasks related to making that happen are listed here and should be linked here as they come around.

As of 09d06ee, the project explicitly states that only serpent 2.1.29 settings file. 2.1.30 is also out, but some institutions may not use the most recent version of SERPENT, or even SERPENT 2. This issue serves as a collection of all the tasks/issues/pull requests related to extending our functionality towards other versions of SERPENT without losing the functionality of this project.

I will add some tasks here as they are realized, and possibly add those issues to a new projects board.

The main thing to look for is how variables are named across versions. Previous versions of SERPENT may have called a property multiple names. Before B1 homogenization was implemented, infinite medium cross sections were stored as TOT, rather than INF_TOT for example. If we want a script that works for outputs from serpent 1.0.0 to work for other versions as well without the user having to rename stuff, then we should be careful and open about how we treat these variables. I think this would be a great benefit for this project and for the users of this project.

If we come across a version that has a totally different output format, then we will have to implement a new version-specific reader for that file and version. This could be done with more subclassing and abstraction, but could get really tricky. 🤞 they don't change outputs too much

Subtasks

These are the big tasks, from my perspective, that will need to be accomplished in order to support additional versions.

• Develop a systematic way to compare output files across SERPENT versions and identify what variables have been dropped, included, or modified.
• Implement a method for renaming variables automatically, TOT stored under infTot to match the overall function of the project
• Identify and document what functionality, if any, we are not able to support from previous versions.
• Document what variables are remapped. The rstVariableSets script does a decent job at this by building off the convertVariableNames function

Some thoughts

We could create an additional repository that contains a basic reference model and directories for each serpent version. Each serpent version would be tasked with running the identical input file and producing the same output files*. An automated script could produce summary files of the data contained in each output file that could be compared across versions, e.g. a sorted list of all variables present in the results file. This knowledge can be used to inform the decisions in subtask 2.

Furthermore, this repository could be used to run more in-depth integration tests on a variety of serpent versions. There's some stuff we can do with submodules where we could link the two repositories together, maybe do some weekly/monthly TRAVIS testing to try and catch mistakes and breakable changes. It would be ideal if this level of testing could be integrated directly into this repository, so we can judge pull requests off their ability to not break support for previous versions as well.

[drewejohnson]

Closing as issues are not good places for wishlists/discussion. They tend to sit here and not have any activity