mistra-uea / mistra Goto Github PK

The directory kpp/ appears to contain a modified version of KPP for use with Mistra. Having a custom version means we need to keep the mistra branch of KPP in sync with the master branch which may prove tricky to do. @JosueBock can you provide information on this, please?

Need to make sure that all scripts are csh scripts, for consistency.
At the moment the following scripts are bash scripts:

• src/plots/newfold.sh
• param/param_jjb1
• src/plots/make_ps.sc

In str.f, we should include a program str / end program str statement to make it clearer, where the main programme starts/end. Also, it is not quite clear, why the file is called str and we should consider to rename the file main routine to mistra.

I am using the version of KPP provided with Mistra.
I tried to compile the model but it fails:

cd src/mech
make

KPP is parsing the equation file
Fatal error : atoms : can't read file

It seems atoms is required by src/mech/master.spc but there is no file with that name in the directory. Is there a file missing?

@pb866 did you manage to compile without errors?

• Add LaTeX files (including figures) of the manual to the doc/ folder, so that it can be updated.
• Add a CHANGELOG file to the main directory summarizing the changes since version 7.4.1 (I think this was the starting version of @JosueBock development work)
• Add a CREDITS file to the main directory with the names of everybody who has contributed code over the years (this may require some digging, so let's start with the current list of names).
• Any outstanding issues and things to do/check/fix/improve (and other things that need to be kept in mind for future development) should be listed as open issue on the github issues page.
• There needs to be a little more explanation on how to use the model than the few lines in the README file.

Conversion of the entire codebase to Fortran 90 (as mentioned in issue #6). This is partially done, but not completely. @JosueBock what is the current status?

We should consider whether EUPL is the most appropriate licence for Mistra.

As I understand it, the EUPL was developed by the EU to cover the work of the commission and potentially of other EU funded projects. While nothing prevents its adoption by other projects, it seems an odd choice for Mistra for the following reasons:

1. Mistra is scientific software and, by definition, science is international. Therefore it is irrelevant whether the licence is fully compatible with EU law or translated into all the EU languages.

2. Most of the development of Mistra was not EU funded. Only a fraction of the work by @JosueBock that created the current version was funded by the EU, before they pulled the plug. The rest was done on a voluntary basis.

3. Most of the users and developers - past and present - of Mistra are, or soon will be, outside the EU. This is not particularly important per se, it just means an EU centered licence is not relevant.

I think Mistra should be under a licence with global applicability and widely known/understood all over the world, especially within the scientific community. Personally, I think that it would be more appropriate to use either the GPL licence or, if we want to be more permissive, the MIT or BSD licence (see this website https://tldrlegal.com/ for more info).

There has never really been a discussion about this. I think we need to discuss it now and decide before the paper is ready to be published. Any thoughts/opinions @pb866, @JosueBock, @cereevesUEA?