configuration file parser about tmlqcd

[Siebren]

I feel this issue can use a few more detailed comments, so let me list a few points that come up here. Some might just be bugs that can be fixed separately.

• Setting the boundary conditions to an integer phase does not work.
  For example,
  ThetaT = 1
  Is discarded as an input, not even generating an error, and reverting to the default value of 0, whereas
  ThetaT = 1.
  works as intended.
• UseEvenOdd can be used both in main input, and inside monomials when running the inverter, where only the one inside the monomial is actually used. So an input file like this:

UseEvenOdd = no
BeginOperator TMWILSON
EndOperator

Will give the following output:
"# Even/odd preconditioning is not used"
"# Using even/odd preconditioning!"

And eventually WILL use even-odd preconditioning, because when UseEvenOdd is omitted inside the monomial, the default value (which is ON), will be used. The UseEvenOdd parameter in the main input should not even be parsed here.

[kostrzewa]

I've looked into a number of options and to be honest FLEX/BISON are pretty reasonable ones. Using libxml2 (which I guess would be the standard choice for us) involves writing a hell of a lot of element parsers [1] which are no simpler to maintain than read_input.l.

The second problem you mention is a bug and should be fixed. The first problem should also be easy to fix by making the dot in the FLT pattern optional (as the exponent is already optional this should not be a problem)

Having said that, I think read_input.l currently does not match read_input.c because when I run flex -t -Ptmlqcd read_input.l > read_input.c the output is not only different, but it also breaks the parser at StartCondition

[1] http://xmlsoft.org/example.html

[kostrzewa]

I'm running through the current read_input.l and there are some inconsistencies with the current sample input files. For instance, the pattern for kappa is "Kappa" inside the monomial but "kappa" in the global settings. The sample input files use the lowercase spelling everywhere and so it clearly fails.

The default hmc.input had the wrong spelling for StartCondition and so it failed.

Does someone have a read_input.l that reads the samples cleanly? I could fix it, of course, but it seems like someone has already done so in the past and committed only read_input.c

[kostrzewa]

Okay, reading floats works in any imaginable combination now through the change suggested above.

[kostrzewa]

Work tracked in branch read_input, currently at #45

[urbach]

the parser is case insensitive...

[urbach]

if you use the correct flex command... so, I didn't put in many grammar rules.

[kostrzewa]

On 28/01/12 18:17, Carsten Urbach wrote:

if you use the correct flex command... so, I didn't put in many grammar rules.

Yes, I noticed that when I looked at the Makefile for the parser. I
should have corrected my post here. Sorry about that.

[annube]

A comment on xml. I dont know how one could organize a C implementation of an xml parser. But for C++ i have a very efficient code which is just one class in a header file of 416 lines of code.
I think its possible to make a C port of this with a little less confort.

[annube]

I prepared a little demonstration:
http://www-zeuthen.desy.de/~annube/xml.parse.tar.gz
make and run with
./xml.parse -f test.xml
try uncommenting and commenting line #3

[kostrzewa]

Hi Andreas, I looked at your example and I really like the fact that it is so short. Correct me if I'm wrong, but it doesn't seem to support nested structures. The flex parser is just fine for parsing lists of parameters (even though your xml parser is clearly shorter) but it has no support for tree structures. This would be the area that XML could help in giving a persistent, dynamically generated tree for different monomials, timescales, operators, and - in subbranches - solvers and integrators and so on.

[annube]

Hi Bartek, I found the newest version of this xml parser class (at home where I used it for another project). The trick was to allow an instance of this class to be a "parameter" again such that you are able to build up a hirarchical structures. With this newer version it is possible to nest structures to an arbitrary degree. I updated the demonstration. Its available under the same link.

[kostrzewa]

I think we should look into this a bit more seriously after all. The main problem with lex as far as I can tell from experience is that one is forced to make changes to many different places at once, thus making it very painful to add or change behaviour. (I just spent one hour doing something which should be very easy but I'm still not done)

These are the steps one has to go through to get a new parameter working (or change an existing one)

• read_input.l
  • add variable to hold parameter
  • add parser for parameter
  • set default value
  • make sure reread does not require any special treatment
  • add %x element unless it is part of a Begin* / End* construct
• read_input.h
  • add extern variable to hold parameter
• global.h
  • add global variable if parameter is meant to be global
• default_input_values.h
  • define default value for parameter

Plus, if parameters are meant to be local to a given Begin* construct, need to treat parameters in operator, monomial, measurement initializers and add* functions

[deuzeman]

Would the MiniXML library (http://www.minixml.org/) be an option? It's ANSI C, really small compared to libxml2, supports nesting and seems to be easy enough to traverse. Apparently it was written and is used and actively maintained by the people maintaining CUPS, so there's some weight behind it too.

[kostrzewa]

Minixml really does look very good. It seems to be implemented using callbacks which should make conditional parsing scenarios relatively simple to deal with. I would be a bit worries about support on our target platforms as there appear to be problems compiling it on Solaris as well as OS-X 10.4

[deuzeman]

Agreed, this is something we need to check. But the issues reported seem to relate to mxmldoc, which we don't need, and specifically the availability of a specific threading framework. I've actually turned off threading in my test compilations, because I'm not sure how well it would play with OpenMP and MPI, or on hardware such as the BG (BG/L didn't support threading at all, I believe). That should keep us reasonably safe, shouldn't it?

[kostrzewa]

On 03/27/2012 01:11 PM, Albert Deuzeman wrote:

I've actually turned off threading in my test compilations, because I'm not sure how well it would play with OpenMP and MPI, or on hardware such as the BG (BG/L didn't support threading at all, I believe). That should keep us reasonably safe, shouldn't it?

In general there should not be any problems because OpenMP simply uses
pthreads. Launching other thread(s) should not have a "destructive"
impact on either MPI or OpenMP, as long as all the functions called from
those threads are thread-safe. (I don't know how minixml uses threading
at this point). As for the BGL supporting threading or not, I don't know.

Bartek

[deuzeman]

Hmm, I suppose they took the care to make their library thread-safe when they decided to use them, so perhaps we're fine there. But for our purposes, we probably won't have many benefits from threading either. We shouldn't be spending too much time parsing XML if we do things right. And when we do, we probably want to be sure to get all the info we need before we move one, pretty much enforcing a serial approach. So if there are any compatibility or availability issues on the pthread side, we should be able to work around them without much of a penalty.

[urbach]

I would think that it might not be worth pushing this right now. Don't we have too many other things to do?

[kostrzewa]

There seems to be a real short-term need for more flexibility due to smearing and how variably it can be used for different measurements. Other than that, I do agree that we can work with what we have. Maybe we can have a short chat about Albert's requirements after the skype conference today?

[urbach]

yes, thats a good idea, lets talk about it after the skype conference!

[kostrzewa]

I think this is sort of settled. I'll close it.