[ET Trac] [Einstein Toolkit] #791: Output timer tree as XML

[Einstein Toolkit]

#791: Output timer tree as XML
--------------------------+-------------------------------------------------
  Reporter:  hinder       |       Owner:  eschnett   
      Type:  enhancement  |      Status:  reviewed_ok
  Priority:  minor        |   Milestone:             
 Component:  Carpet       |     Version:             
Resolution:               |    Keywords:             
--------------------------+-------------------------------------------------

Comment (by hinder):

 Yes, I thought about the fact that output could be lost, and the
 implications for appending and renaming.  I agree with what you say, and
 indeed this can be added later.

 Regarding the schema, I have found practically that it is useful to have
 lists of elements enclosed by a single common element.  That means I can
 ask for all the members of <children>.  On the other hand, I probably
 should only look at elements that I know, to make the format extensible,
 so in the end maybe the <children> tag is not necessary.  I will have to
 restrict to elements of the correct tag anyway.  I will likely change the
 schema in the near future because at the moment it's a little annoying to
 process.

 Yes, the output accuracy should be fixed.

 Regarding the output filename, I used to agree, but now I don't :)
 Sorting with ls is only one use case.  A more useful thing to do is to
 programatically load the timers via a loop, or from a specific process, in
 which case you are given an integer and want to find the filename.  At the
 moment, for the carpetlib timers, I have to load all the filenames, parse
 all the 0004 etc into integers, and then select the filename which
 corresponds to the integer I want.  Having the actual process number in
 the filename would make this much more straightforward.  The fact that ls
 doesn't have the ability to sort filenames with numerical components into
 numerical order shouldn't force us to adopt an inelegant solution.
 Another problem is that the number of leading zeroes is hard-coded.
 Anyway, we eventually shouldn't have per-process output files anyway; the
 data should all be sent to the root process and added to a single XML
 file.

 The original patch was committed as
 http://www.carpetcode.org/hg/carpet/index.cgi/rev/27ddee06ff1d.

 I have another patch relating to this:
 http://www.carpetcode.org/hg/carpet/index.cgi/rev/e0e84d10eac8

 This second patch allows you to include the historical values of the
 timers (i.e. every time they are stopped) in the XML file.  This allows
 you to determine if the run times for each routine are consistent, or if
 they "jitter".  This was very helpful for optimising performance.  There
 is no information about the coordinate time or iteration number, as this
 is not available to the TimerNode class.  I'm not sure if it's possible to
 get that.  A Carpet function get_current_iteration() would be helpful.  Is
 there a global notion of current iteration?  We would still have multiple
 entries for each iteration (e.g. for MoL substeps).  Each time is stored
 in a vector<double> every time the timer is stopped.  Could this be a
 problem?  Might it grow large?  Maybe this could be stored conditionally
 on the parameter being set?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/791#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit