[Users] Meeting Minutes 2022-9-15

[Roland Haas]

Hello all,

Sorry for not making it, was chatting with locals.

>New ET modules:
>* no news on Canuda review

I will poke Taishi about his verdict. Asduming the expected positive response we can vote on inclusion in the call next week (and announce on the vote soon).

>* Haley has addressed reviewers' comments for FLRW solver

I will poke Zach about his verdict. Asduming the expected positive response we can vote on inclusion in the call next week (and announce on the vote soon).


>* Sam has addressed reviewers' comments for selfforce-1d;

I will poke Peter about his verdict. Asduming the expected positive response we can vote on inclusion in the call next week (and announce on the vote soon).


>  only remaining task is to regenerate the FORD documentation

Must be done for the release anyway (so not a blocker right now).


>* Leo has addressed reviewers' comments for NRPyEllipticET;
>  notebook which generates the code is not yet ready, but this
>  is currently being worked on

I will poke Cheng-Hsin and Guiseppe about their verdict. Asduming the expected positive response we can vote on inclusion in the call next week (and announce on the vote soon). The notebook is mot usually reviewed (since NRPy+ is not in the ET), only the generated code.


>* 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


I suggest to treat this as a regular Baikal update with regular pull request and ticket which makes review open to all who want to give it a try.

>
>
>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.

I woukd suggest to REQUIRE: Carpet tge include carpet.hh then use Carpet::timerefsfacs (or so) which is a C++ vector of tbe factors.

>
>* 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.

Such a policy exists: 


https://docs.einsteintoolkit.org/et-docs/Policies_to_retire_functionality

>
>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.

It is not easy to e en.do the "every n steps".



>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.
>

yup.

Yours,
Roland