#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?