The Zero Notebook for GEOframe components

There is the necessity to properly document the code we developed.  The state-of-art is that many Jupyter Notebooks were written to document may of the actions requested for running them. These Notebooks are made available when to sample projects are downloaded through their osf (which stands for Open Science Framework)  repository. This is probably a temporary solution which will be unified once forever in Github. However, these notebooks, see for instance the case of the Winter School  ofter are missing of an overall description which conveys all the information regarding the Component, part of which, for some component, was written in a custom LaTeX format and made available through the GEOframe blog. To make some order, I am proposing here to put the basic information in a Notebook, whose template you can find by clicking on the Figure below.

The notebook is a work-in-progress and who wants to give suggestions is welcomed. There are other two scopes for this Notebook Zero,  one is that the materials it contains can serve for a chapter in a Thesis where the component is described for its informatics and its content, with minimal modifications;  the other,  that it could be used for a possible submission of the component code to JOSS.  The latter goal would require some improvement in our GEOframe component Github site though in order to have tagged version of the software, a clean way to submit issues (a issue tracker), a set of unit test for the continuous integration of the components. We made a lot of progresses in recent years, but we are not yet there, really operational. A companion issue is where we do upload the .sim files and the data corresponding to tagged version of the components. So far they were assembled together in someone computer, compiled, eventually uploaded to Zenodo (or OSF) and made public. Streamlining the whole process in Github would be probably convenient. Going even more general, there is an installing problem of the OMS/GEOframe stuff. So far we replicated the jars (i.e. the Java executable) several times, each time we needed a a new project. It is time, I guess, to have the executable in a unique place, at Computer or User level, while the directories with data etc (so fare recognised as the OMS projects), freely replicable for different simulations, but without having to get along any time with copies of the executables.

Fair use: It is easy to make custom versions of our software components and embed it into some "proprietary platform" or "commercial" product.  We do not prohibit this use. However, it should be reminded that GPL 3.0 of the component would require a redistribution of modifications of our codes. 

Besides, even its use would require a note, somewhat visible that makes clear the product is powered by GEOframe. So we expect that fair use of our software in some enterprise would be acknowledged by: "Powered by GEOframe and OMS3".