Open tjhei opened 8 years ago
Well, this has disadvantages as well. For example, if you do this kind of processing, the line numbers you get from ParameterHandler
are all off. I would find that rather awkward.
I think the current system is not all too restrictive. In particular, the only requirements are that the dimension and additional shared libs are in the main .prm file. I think that's a reasonable restriction (which we should probably document, though).
the line numbers you get from ParameterHandler are all off.
Oh, you are right. I thought ParameterHandler would do a c-preprocessor style pasting of strings, but looking at it now that is not the case.
Another disadvantage of the current system is, that every single process will open the files for reading. I don't know if that is much of a problem in practice though. @gassmoeller didn't you make a changeto broadcast file data from proc0 somewhere else in the code? Why was that?
His changes were to reading data files. You could do the same for the main .prm file, of course -- this would cover 98% of use cases, assuming that there are any users at all who use the include mechanism.
I did my changes mostly, because when measuring I/O traffic for one of our models the data input operations actually created more traffic than the output, because it was duplicated on 1000 processes. I doubt loading the .prm file is heavy traffic, although opening a file on thousands of processes might be a bit troublesome for the file system as well. Anyway, I think it is ok for a few kB of input file (we had megabytes of data to load).
deal.II allows statements
inside parameter files. While this works somehow, all our custom logic to find dimension, shared libs, etc. doesn't work so those statements need to be in the original .prm.
A fix would involve:
I will do this after 1.4 when we can remove support for older deal.II versions so we can remove the backslash preprocessing.