[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