Merged
Conversation
The new struct is typedefd as configInfo. It contains all the information which was
previously stored in inputPars: the difference is that inputPars has now been trimmed to
contain _only_ those parameters which are settable by the user in the model.c file. Any
non-user-settable values should now be added to the config struct.
The advantages of this are as follows.
- We will usually want more config parameters than user-settable ones. The separation
leaves it clearer which things the user needs to (or can) set.
- The separation makes it easier to check for and exclude impossible combinations of
parameters.
- We can adopt new names (for clarity) for config parameters without bothering the
user with a changed interface.
Two small unrelated additional changes:
- A new macro MAX_NIMAGES is defined in lime.h and used in the initial malloc of struct image
instead of MAX_NSPECIES as before.
- Fixed the order of functions in lime.h so they are all (instead of just mostly, as before)
alphabetical.
This input parameter had no present function in the code, so was removed from there in the previous commit. Now I also removed mention of it from the user manual.
allegroLeiden
force-pushed
the
inpars
branch
from
d65e6b5 to
430f151
Compare
Merged
Contributor
Author
|
I guess you mean |
Contributor
|
O yes: #ifndef LIME_H |
Following advice from @rschaaf I have created a separate header file inpars.h just to define the struct for the user-input parameters. I also included macros in both lime.h and inpars.h to prevent multiple inclusion of these files. The final change was to the interface of openSocket(). This had the inpars struct as one of its arguments, the other being the species ID, but it turns out that all it needs is the name of the moldatfile for that species. Thus I replaced the former two arguements by a single char * moldatfile.
Contributor
Author
|
I just force-pushed a commit which includes the macro test you proposed @rschaaf-aifa but undoes the move of the function prototypes to inpars.h. Hope I have not mangled the commit log too much. |
Merged
This was a pretty difficult merge. In my hacks I tried to preserve the principle that ONLY the user-settable inpars should be passed between functions at the top level inside main(), i.e. that the new configInfo stuff should be sequestered inside run().
Contributor
|
I've just merged your PR #105 and now this branch has conflicts again... Sorry about this. Let's us first merge this one so you don't have to fix conflicts in your other branches over and over again. |
Contributor
Author
|
Serial conflict fixing seems to be unavoidable when the PRs have built up like this. I think we should try to be a bit more sequential with the next release. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The intent of this is to separate the previous single inpars struct into two: one which contains ONLY those parameters the user can set, and the other for general program information (which may include some of the user pars). Besides using different variables to express different functionality, this makes it easier to change names for example without affecting the user interface. I had to make minor changes to code in a lot of places, but the result (i) compiles, (ii) passes valgrind tests, and (iii) produces an identical image to the previous.