I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look:
https://svn.cactuscode.org/flesh/branches/with_piraha
This version is able to run the ET testsuite.
This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings.
It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions.
Some debug printing is in place so you can get an idea of what's going on.
Cheers, Steve
On 7 Feb 2013, at 01:37, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
I've hacked a version of Cactus to use Piraha for parameter parsing.
For those who don't know, Piraha is a parsing framework/library based on Parsing Expression Grammars (PEGs). This allows you to define the grammar of a language using a simple regular-expression-type language, and Piraha will use this to decode an input file into a hierarchical data structure of the parsed data (a "parse tree"). See http://code.google.com/p/piraha-peg/, http://en.wikipedia.org/wiki/Parsing_expression_grammar. I have used Piraha (in its Java form) and found it very useful and quite easy. Parsing input files using a formal grammar is much easier and more "correct" than writing a custom parser by hand. I highly recommend it if you need to process textual input!
On 02/06/2013 06:37 PM, Steven R. Brandt wrote: I haven't heard a lot of feedback about this feature yet, but I thought I'd mention a recent improvement.
Piraha allows array notation in parameter files so that instead of writing this:
CarpetRegrid2::radius_1[1] = 10 CarpetRegrid2::radius_1[2] = 5
you can write this: CarpetRegrid2::radius_1 = [10,5]
The nice thing about having a parser is that the various features combine, so you can also write this: CarpetRegrid2::radius_1 = [ 2+2*4 # This should be 10 ,5]
I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look:
https://svn.cactuscode.org/flesh/branches/with_piraha
This version is able to run the ET testsuite.
This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings.
It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions.
Some debug printing is in place so you can get an idea of what's going on.
Cheers, Steve
On 21 Feb 2013, at 00:57, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
On 02/06/2013 06:37 PM, Steven R. Brandt wrote: I haven't heard a lot of feedback about this feature yet, but I thought I'd mention a recent improvement.
Piraha allows array notation in parameter files so that instead of writing this:
CarpetRegrid2::radius_1[1] = 10 CarpetRegrid2::radius_1[2] = 5you can write this: CarpetRegrid2::radius_1 = [10,5]
The nice thing about having a parser is that the various features combine, so you can also write this: CarpetRegrid2::radius_1 = [ 2+2*4 # This should be 10 ,5]
I support the use of Piraha in the flesh for its parsing. It should be used for parsing the CCL files during the CST, and parsing the parameter file at runtime. I see that Piraha is written in C++, so we would have to relax the restriction that the flesh can only contain C code. I have not yet looked at the code.
One important aspect is error messages. How well does Piraha currently report input errors to the user? Are they easy to understand? I have found piraha error messages to be a little confusing in the past :)
I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look:
https://svn.cactuscode.org/flesh/branches/with_piraha
This version is able to run the ET testsuite.
This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings.
It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions.
Some debug printing is in place so you can get an idea of what's going on.
Hi,
On Fri, Feb 22, 2013 at 02:11:22PM +0100, Ian Hinder wrote:
I see that Piraha is written in C++, so we would have to relax the restriction that the flesh can only contain C code.
I don't see a reason for this restriction anymore. In fact, using C++ would make some of this code much more readable and maintainable. Speaking if C++ in the flesh: How strict was this in the past anyway; looking at src/main/flesh.cc from 1998, written by Tom? Of course, this is just a minimal C++ program, not using any of the features that past C++ compilers could have stumbled over.
It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions.
Is there a way to tell Cactus to save error messages to a file? If so, we should use this to create testsuites testing error detection...
Frank
On Fri, Feb 22, 2013 at 10:09 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
On Fri, Feb 22, 2013 at 02:11:22PM +0100, Ian Hinder wrote:
I see that Piraha is written in C++, so we would have to relax the restriction that the flesh can only contain C code.
I don't see a reason for this restriction anymore. In fact, using C++ would make some of this code much more readable and maintainable. Speaking if C++ in the flesh: How strict was this in the past anyway; looking at src/main/flesh.cc from 1998, written by Tom? Of course, this is just a minimal C++ program, not using any of the features that past C++ compilers could have stumbled over.
The main program needs to be written in C++ to allow linking with other C++ code. At that time, the flesh was pure ANSI C.
However, times have changed. Carpet has proved that C++ is possible and efficient on any interesting system. Our current policy is to allow C++ features, in particular if they lead to "better" (simpler) code, and if the code is portable. That means in particular that C++11 features are probably not a good idea, but using e.g. STL containers would be nice. In other cases, preprocessor magic and code duplication may be replaced by templates.
-erik
On 02/22/2013 09:14 AM, Erik Schnetter wrote:
On Fri, Feb 22, 2013 at 10:09 AM, Frank Loeffler <knarf@cct.lsu.edu mailto:knarf@cct.lsu.edu> wrote:
Hi, On Fri, Feb 22, 2013 at 02:11:22PM +0100, Ian Hinder wrote: > I see that Piraha is written in C++, so we > would have to relax the restriction that the flesh can only contain C > code. I don't see a reason for this restriction anymore. In fact, using C++ would make some of this code much more readable and maintainable. Speaking if C++ in the flesh: How strict was this in the past anyway; looking at src/main/flesh.cc from 1998, written by Tom? Of course, this is just a minimal C++ program, not using any of the features that past C++ compilers could have stumbled over.The main program needs to be written in C++ to allow linking with other C++ code. At that time, the flesh was pure ANSI C.
However, times have changed. Carpet has proved that C++ is possible and efficient on any interesting system. Our current policy is to allow C++ features, in particular if they lead to "better" (simpler) code, and if the code is portable. That means in particular that C++11 features are probably not a good idea, but using e.g. STL containers would be nice. In other cases, preprocessor magic and code duplication may be replaced by templates.
I believe that when the decision was made to not allow C++ templates were an unstable feature and compilers could not reliably compile the STL. But I agree with Erik. C++11 is not a good idea. In fact, I think we might require that the flesh compile with -std=C++03 or something.
-erik
-- Erik Schnetter <schnetter@cct.lsu.edu mailto:schnetter@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/
Hi Frank,
I worked on warn_callback and info_callback back in 2005. It seems they have been added to the trunk.
https://svn.cactuscode.org/flesh/trunk/src/main/WarnLevel.c
I sent around a sample implementation that dump all info and warn to files. Since the function iterates through all registered callbacks, there could be multiple ways warn and info could be handled.
I will try to find a sample implementation and send to the list.
Regards, Jian On 02/22/2013 09:09 AM, Frank Loeffler wrote:
Is there a way to tell Cactus to save error messages to a file? If so, we should use this to create testsuites testing error detection...
Frank
On 22 Feb 2013, at 16:57, Jian Tao jtao@cct.lsu.edu wrote:
Hi Frank,
I worked on warn_callback and info_callback back in 2005. It seems they have been added to the trunk.
https://svn.cactuscode.org/flesh/trunk/src/main/WarnLevel.c
I sent around a sample implementation that dump all info and warn to files. Since the function iterates through all registered callbacks, there could be multiple ways warn and info could be handled.
I will try to find a sample implementation and send to the list.
The test mechanism will currently report the test as failed if Cactus returns a nonzero exit code. We would need to add a parameter (probably to the flesh) to tell it to return a zero exit code, and to write the error message to a file. We would then need the test mechanism to be able to reliably diff the error message text. At the moment, I think the test mechanism assumes that output files are columns of numbers; is that correct?
Regards, Jian On 02/22/2013 09:09 AM, Frank Loeffler wrote:
Is there a way to tell Cactus to save error messages to a file? If so, we should use this to create testsuites testing error detection...
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
The call back functions just provide a way to customize the handling of warn and info output. Since all the registered handlers are iterated, a new handler doesn't replace the old handler.
Some changes are necessary to change the default behaviour for failed test runs. As for comparing the output files, it is currently done with a perl script basically doing a diff. I would again suggest that we move to HDF5. Also some performance test would be also good in line with success/fail test.
Recently I started looking into a project called Codespeed. A sample usage can be found at http://speed.pypy.org/timeline/ We might want learn something from it.
Regards, Jian
On 02/22/2013 10:10 AM, Ian Hinder wrote:
On 22 Feb 2013, at 16:57, Jian Tao jtao@cct.lsu.edu wrote:
Hi Frank,
I worked on warn_callback and info_callback back in 2005. It seems they have been added to the trunk.
https://svn.cactuscode.org/flesh/trunk/src/main/WarnLevel.c
I sent around a sample implementation that dump all info and warn to files. Since the function iterates through all registered callbacks, there could be multiple ways warn and info could be handled.
I will try to find a sample implementation and send to the list.
The test mechanism will currently report the test as failed if Cactus returns a nonzero exit code. We would need to add a parameter (probably to the flesh) to tell it to return a zero exit code, and to write the error message to a file. We would then need the test mechanism to be able to reliably diff the error message text. At the moment, I think the test mechanism assumes that output files are columns of numbers; is that correct?
Regards, Jian On 02/22/2013 09:09 AM, Frank Loeffler wrote:
Is there a way to tell Cactus to save error messages to a file? If so, we should use this to create testsuites testing error detection...
Frank
_______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 02/22/2013 07:11 AM, Ian Hinder wrote:
On 21 Feb 2013, at 00:57, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
On 02/06/2013 06:37 PM, Steven R. Brandt wrote: I haven't heard a lot of feedback about this feature yet, but I thought I'd mention a recent improvement.
Piraha allows array notation in parameter files so that instead of writing this:
CarpetRegrid2::radius_1[1] = 10 CarpetRegrid2::radius_1[2] = 5you can write this: CarpetRegrid2::radius_1 = [10,5]
The nice thing about having a parser is that the various features combine, so you can also write this: CarpetRegrid2::radius_1 = [ 2+2*4 # This should be 10 ,5]
I support the use of Piraha in the flesh for its parsing. It should be used for parsing the CCL files during the CST, and parsing the parameter file at runtime. I see that Piraha is written in C++, so we would have to relax the restriction that the flesh can only contain C code. I have not yet looked at the code.
One important aspect is error messages. How well does Piraha currently report input errors to the user? Are they easy to understand? I have found piraha error messages to be a little confusing in the past :)
I think my error messages are pretty good. There are probably going to be some confusing cases. Here are some examples. Please view with fixed width font to see where the ^ points.
Activating thorn Cactus...Success -> active implementation Cactus ERROR IN PARAMETER FILE: In rule 'file::set::par' Line=58 Carpet:domain_from_coordbase = "yes" ^ Expected character: :
ERROR IN PARAMETER FILE: In rule 'file::set::aexpr::mexpr::value::var' Line=59 Carpet::ghost_size_x = 1+1+*1 ^ Expected character: \t\r\n#(-+0-9."@a-zA-Z_$
This next one is a bit tricky...
Activating thorn Cactus...Success -> active implementation Cactus ERROR IN PARAMETER FILE: In rule 'file::set::par' Line=59 Carpet::init_fill_timelevels = "yes"
Here's the par file code, as you can see a quote is missing. Because we have multiline quotes, the actual error doesn't show up until the next line. There's not too much I can do about that.
58 Carpet::domain_from_coordbase = "yes 59 Carpet::init_fill_timelevels = "yes" 60 Carpet::ghost_size_x = 1+1+*1
I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look:
https://svn.cactuscode.org/flesh/branches/with_piraha
This version is able to run the ET testsuite.
This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings.
It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions.
Some debug printing is in place so you can get an idea of what's going on.
On Wed, Feb 20, 2013 at 05:57:03PM -0600, Steven R. Brandt wrote:
I haven't heard a lot of feedback about this feature yet, but I thought I'd mention a recent improvement.
I have a production run using your (earlier) changes currently running. It is not using any of the new features, but is a test whether the changes work besides the testsuites for at least one production parfile.
Piraha allows array notation in parameter files so that instead of writing this:
CarpetRegrid2::radius_1[1] = 10 CarpetRegrid2::radius_1[2] = 5you can write this: CarpetRegrid2::radius_1 = [10,5]
That's cool. :)
The nice thing about having a parser is that the various features combine, so you can also write this: CarpetRegrid2::radius_1 = [ 2+2*4 # This should be 10 ,5]
I can see this coming in handy.
Frank
On Wed, Feb 06, 2013 at 06:37:41PM -0600, Steven R. Brandt wrote:
I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look:
https://svn.cactuscode.org/flesh/branches/with_piraha
This version is able to run the ET testsuite.
I used with for one of my production runs, without any problem whatsoever.
I would like to see it committed to the dev-version. Otherwise it would never see a wide testing audience and be used. We can always 'take it back' in case of problems, or fix it.
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Jian Tao -
Steven R. Brandt