Is there a way to graphically display cactus timer data? We're thinking about having an REU student develop such a tool if it doesn't exist. Thanks.
--Steve
On 22 May 2017, at 21:35, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Is there a way to graphically display cactus timer data? We're thinking about having an REU student develop such a tool if it doesn't exist. Thanks.
Hi Steve,
Not that I know of. What sort of graphical display are you thinking of? Anyone can plot the Carpet timing variables (physical_time_per_hour as a function of time) etc in whatever they usually use to make plots of Cactus data.
If you are thinking of the detailed timers used to profile the different parts of the code, then it would be good to have something to make a quick plot of these. They could take the timertree.*.xml files and produce a hierarchical display of the timers. This could be a tree or a pie chart. I have done this before using Mathematica. Some of the things I did were:
– Selecting a threshold so that timers which contribute a small amount are omitted, otherwise there are too many timers to display – Creating "groups" (via string patterns) so that you can logically group things together (e.g. you might want to merge all the different McLachlan RHS timers into a single one) depending on the analysis you are doing
It would be good to have a tool, maybe based on Python and Matplotlib, to generate such plots quickly and simply. One issue is that the timer XML files are only written at the end of the simulation, and their content is not reduced among processors. It is usually quite important to consider all the processors, not just the first one, so we should think about how this should be done. Depending on what you want to achieve, it could also be useful to output the XML files regularly, though then you have to think about whether it's important to keep the historical data, or just replace with the current totals. It also leads to a large number of output files since we have one per process. This is why I don't enable this timer output in my own simulations, except when explicitly benchmarking/profiling.
Perhaps you could create a page under "projects" on the ET wiki and we can make notes and suggestions there?
Thanks, Ian. Yes, we were thinking of the detailed timers and we were thinking about making a modification to provide live data. We'll make the project soon.
--Steve
On 05/23/2017 02:17 AM, Ian Hinder wrote:
On 22 May 2017, at 21:35, Steven R. Brandt <sbrandt@cct.lsu.edu mailto:sbrandt@cct.lsu.edu> wrote:
Is there a way to graphically display cactus timer data? We're thinking about having an REU student develop such a tool if it doesn't exist. Thanks.
Hi Steve,
Not that I know of. What sort of graphical display are you thinking of? Anyone can plot the Carpet timing variables (physical_time_per_hour as a function of time) etc in whatever they usually use to make plots of Cactus data.
If you are thinking of the detailed timers used to profile the different parts of the code, then it would be good to have something to make a quick plot of these. They could take the timertree.*.xml files and produce a hierarchical display of the timers. This could be a tree or a pie chart. I have done this before using Mathematica. Some of the things I did were:
– Selecting a threshold so that timers which contribute a small amount are omitted, otherwise there are too many timers to display – Creating "groups" (via string patterns) so that you can logically group things together (e.g. you might want to merge all the different McLachlan RHS timers into a single one) depending on the analysis you are doing
It would be good to have a tool, maybe based on Python and Matplotlib, to generate such plots quickly and simply. One issue is that the timer XML files are only written at the end of the simulation, and their content is not reduced among processors. It is usually quite important to consider all the processors, not just the first one, so we should think about how this should be done. Depending on what you want to achieve, it could also be useful to output the XML files regularly, though then you have to think about whether it's important to keep the historical data, or just replace with the current totals. It also leads to a large number of output files since we have one per process. This is why I don't enable this timer output in my own simulations, except when explicitly benchmarking/profiling.
Perhaps you could create a page under "projects" on the ET wiki and we can make notes and suggestions there?
-- Ian Hinder http://members.aei.mpg.de/ianhin
The only interfaces I know about were through the web browsers. Dylan Stark did some work with this at CCT before
https://link.springer.com/chapter/10.1007/978-3-540-68111-3_124
I always thought that it would be very helpful to have something that didn’t just report all the data but could tell you something in plain English about how to interpret the information.
On May 22, 2017, at 2:35 PM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Is there a way to graphically display cactus timer data? We're thinking about having an REU student develop such a tool if it doesn't exist. Thanks.
--Steve
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 23 May 2017, at 16:16, Gabrielle Allen gaballen@gmail.com wrote:
The only interfaces I know about were through the web browsers. Dylan Stark did some work with this at CCT before
https://link.springer.com/chapter/10.1007/978-3-540-68111-3_124
I always thought that it would be very helpful to have something that didn’t just report all the data but could tell you something in plain English about how to interpret the information.
I also thought about having something that ran "live" with the simulation, that was aware of how much time different things "should" take, maybe from parameters. For example, you might get a warning that output was taking more than 30% of the simulation time, or horizon finding, or something like that.
Ian — this was the aim of the project that Dylan undertook back in the day — the idea was that the simulation could actually dynamically choose parameters, e.g. instead of saying checkpoint every 1000 time steps, you would set a parameter to say that checkpointing should be no more than 10% of run time; or the code would be able to spot that an analysis method was taking 10x as much time and rachet back how often it was invoked — so both would need to be able to output with warnings, but also take intelligent action based on that (and this is something that I still think Cactus can do quite uniquely).
On May 23, 2017, at 10:17 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 23 May 2017, at 16:16, Gabrielle Allen <gaballen@gmail.com mailto:gaballen@gmail.com> wrote:
The only interfaces I know about were through the web browsers. Dylan Stark did some work with this at CCT before
https://link.springer.com/chapter/10.1007/978-3-540-68111-3_124 https://link.springer.com/chapter/10.1007/978-3-540-68111-3_124
I always thought that it would be very helpful to have something that didn’t just report all the data but could tell you something in plain English about how to interpret the information.
I also thought about having something that ran "live" with the simulation, that was aware of how much time different things "should" take, maybe from parameters. For example, you might get a warning that output was taking more than 30% of the simulation time, or horizon finding, or something like that.
-- Ian Hinder http://members.aei.mpg.de/ianhin http://members.aei.mpg.de/ianhin
Steve
Thorn TimerReport can output timing data as CSV file, which can be imported to Excel or similar applications, which support creating charts. There are also scripting languages (Python, Julia) that can read CSV files and create plots.
-erik
On Mon, May 22, 2017 at 3:35 PM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Is there a way to graphically display cactus timer data? We're thinking about having an REU student develop such a tool if it doesn't exist. Thanks.
--Steve
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Gabrielle Allen -
Ian Hinder -
Steven R. Brandt