Present: Sam, Steve, Keith, Gabriele, Peter, Leo, Zach, Bruno
New ET modules: * no news on Canuda review * Haley has addressed reviewers' comments for FLRW solver * Sam has addressed reviewers' comments for selfforce-1d; only remaining task is to regenerate the FORD documentation * Leo has addressed reviewers' comments for NRPyEllipticET; notebook which generates the code is not yet ready, but this is currently being worked on * Baikal update: Zach hasn't heard back from Helvi. Since the new Baikal is waiting for inclusion, the old Baikal's notebook isn't being maintained in favor of the new Baikal
Other questions: * For the particle tracer Leo is working on, he needs to access the cctk_timefac for the finest level, but cctk_timefac only gives the value for the current time level. He does this by accessing the Carpet parameter time_refinement_factors using CCTK_ParameterGet() but wanted to know if there was a better/more 'proper' way of accessing the parameters. The function is necessary because the parameter is private and cannot be accessed via the interface.
Steve said that this is how he would do it, but Leo should send the question to the mailing list to see if Roland or Erik have other suggestions.
* We would like to shut down the svn servers which aren't being used anymore and have been maintained for preservation of old thornlists for a long time. By shutting them down, we can see if anyone complains about it and also track down anywhere else on the website that might reference them.
* There is no established policy on deprecating or renaming thorns/parameters. Zach proposed that we should set a clear policy for the timescale on which these things can be done, and the procedure for doing so.
* Someone asked about whether there will be recordings of the European ET meeting, but Peter said there were not. However, they do intend to upload the slides at some point.
* Next European meeting was set and will be in Aveiro, Portugal.
Questions on the mailing list: No one answered 'Running with SLURM' from last week; Steve will respond to it. http://lists.einsteintoolkit.org/pipermail/users/2022-August/008667.html
Open tickets: Gabriele brought up ticket issue #2629 https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevolutio... about when one should schedule in CCTK_ANALYSIS vs MoL_PseudoEvolution. The particular concern is how this will interact with parameters such as the calculate_constraints_every in LeanBSSNMoL, as some choices of output_every type parameters will be invalid depending on the number of active refinement levels. However, since these calculations are expensive, it is important to be able to control the calculation to only occur when it will be output.
Zach said that one solution is to just leave it up to the user to decide if it is sane to update these quantities every n timesteps.
This is similar to the issue Leo has been facing with the particle tracer, as it must compute and output only so many iterations. However, Cactus counts iterations based on the smallest possible refinement level, even if it isn't active. This leads to the need to determine the dtfac for the finest possible level, which is the topic of the question raised earlier. He then errors out if the parameters will produce incorrect output.
Since several thorns need this feature, discussion arose on whether this should be provided as an aliased function by Carpet to easily provide access to the needed information to validate the given values of these types of output_every parameters. Carpet could set some out_every_safe that provides the minimal safest out_every.
The chair for next week (9/22) is Leo, and the minutes taker is Bruno.
Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho