[Carpet] expensive logging of CarpetRegrid[2] parameter changes
Bela Szilagyi
szilagyi at aei.mpg.de
Thu Nov 8 13:22:38 CET 2007
I guess there are a few things that collide here.
One is that CarpetRegrid provides interface to its internal mesh-refinement
setup through its parameters. And that, I hope, will stay this way.
The other is that Formaline offers a way of logging parameter changes. This
can help in troubleshooting (or checking proper code behavior) but can lead
to code performance issues if there is a lot of parameter changes.
The temporary fix suggested by Thomas was to exclude Carpet::coordinates from
the list of parameters that are logged.
Another option is to set a parameter in Formaline, e.g.
int::nr_of_parameter_changes_to_be_logged "nr of param changes to be logged"
{
-1: "log all changes"
0: "no logs please"
1*: " log this many changes, then stop logging"
} -1
and in the routine that actually communicates the parameter change logs to
some server add a bit of extra code that will quit the routine in case the
user-set logging quota has been filled.
This should be an easy code change, would make the logging perhaps safer, and
would still allow for the existing parameter steering based algorithms to be
used without excessive logging.
Bela.
On Wednesday 07 November 2007 16:53:37 Thomas Radke wrote:
> Hi,
>
> CarpetRegrid[2] provides steerable parameters as an interface for other
> thorns to change the grid structure. I just found out that those
> parameters are steered rather frequently which then may cause problems
> when runtime parameter changes are to be logged (eg. as thorn Formaline
> can do): logging every individual parameter change becomes
> runtime-expensive, and the logfile may grow to unreasonable sizes.
>
> As a measure to prevent this situation, we could exlude changes for some
> parameters from being logged. I believe this is not a very good solution
> though.
> Instead we should think about changing the way how thorns can interact
> with CarpetRegrid[2]. Maybe they could communicate via grid variables
> instead of steerable parameters ?
More information about the developers
mailing list