Hello, I am running a simulation with Daniel Siegel where we use a base level plus 6 refinement levels, like the following: CarpetRegrid2::radius_1[1] = 336.0 # dx/64 CarpetRegrid2::radius_1[2] = 168.0 # dx/64 CarpetRegrid2::radius_1[3] = 84.0 # dx/64 CarpetRegrid2::radius_1[4] = 42.0 # dx/64 CarpetRegrid2::radius_1[5] = 21.0 # dx/64 CarpetRegrid2::radius_1[6] = 10.5 # dx/64
We ran simulations of a neutrino-driven wind from a Neutron star, out to ~150 ms, and now we want to turn on a high magnetic field. We have tried B-fields of varying strengths, but if we try a B-field strength that is too high, we find errors generated on the innermost refinement level boundary. We believe if we enlarge the innermost box size ie. CarpetRegrid2::radius_1[6] = 10.5 --> ~19-20, these errors would disappear. But we are having trouble doing this. In our attempt, we activate the trigger thorn with the following settings:
ActiveThorns = "Trigger" Trigger::Trigger_Debug = 1 Trigger::Trigger_Once[0]=1 Trigger::Trigger_Number =1 Trigger::Trigger_Checked_Variable[0]="GRHydro::GRHydro_rho_min" Trigger::Trigger_Reduction [0]="" Trigger::Trigger_Relation [0]="<" Trigger::Trigger_Checked_Value [0]= 1.1 Trigger::Trigger_Reaction [0]="steerparam" Trigger::Trigger_Steered_Parameter_Value [0] = "19.32" Trigger::Trigger_Steered_Parameter_Name [0] = "radius_1[6]" Trigger::Trigger_Steered_Parameter_Thorn [0] = "CarpetRegrid2"
(We use a trivially satisfied trigger condition so that the parameter value is reset immediately upon restart.) Since the CarpetRegrid2 variable "radius_1[6]" is not steerable, we had to modify this to make it such. After turning debug on, we see the following output:
INFO (Trigger): Testing triggers INFO (Trigger): last_checked: -1 INFO (Trigger): trigger nr. 0 fulfilled for GRHydro_rho_min (0.000000<1.100000) INFO (Trigger): Steering parameter INFO (Trigger): Parameter steered
Which supposedly successfully resets the value correctly. We believe that even though this may be the case, the actual grid is not changing. We plot the first 2 boundary levels and show them in the attached file.
There must be interpolation of the second innermost grid onto the innermost grid, and we believe this is not actually handled mid-simulation and thus doesn't not result in the change we expect.
Is there any simple way of changing the inner grid easily? Any help is much appreciated!
[image: image(1).png]
Thanks, Dhruv Desai
Hello Dhruv,
At runtime you have to steer the grid scalars in CarpetRegrid2 rather than the parameters.
See the gallery example for hmns: http://einsteintoolkit.org/gallery/bns/nsnstohmns.par
Trigger::Trigger_Checked_Variable[2]="SphericalSurface::sf_valid[2]" Trigger::Trigger_Reduction [2]="" Trigger::Trigger_Relation [2]=">" Trigger::Trigger_Checked_Value [2]=0. Trigger::Trigger_Reaction [2]="steerscalar" Trigger::Trigger_Steered_Scalar [2] = "CarpetRegrid2::num_levels[0]" # == num_levels_1 Trigger::Trigger_Steered_Scalar_Value[2] = "1"
and for the radii you can look up the Regrid2 docs
http://einsteintoolkit.org/thornguide/Carpet/CarpetRegrid2/documentation.htm...
Trigger::Trigger_Steered_Scalar[triggernum] = "carpetregrid2::radii[center]"
from its interface.ccl (center = 0 in your case for radius_1).
You also must set Trigger::Trigger_Steered_Scalar_Index[triggernum] to the level needed (6 in your case).
Yours, Roland
Hello, I am running a simulation with Daniel Siegel where we use a base level plus 6 refinement levels, like the following: CarpetRegrid2::radius_1[1] = 336.0 # dx/64 CarpetRegrid2::radius_1[2] = 168.0 # dx/64 CarpetRegrid2::radius_1[3] = 84.0 # dx/64 CarpetRegrid2::radius_1[4] = 42.0 # dx/64 CarpetRegrid2::radius_1[5] = 21.0 # dx/64 CarpetRegrid2::radius_1[6] = 10.5 # dx/64
We ran simulations of a neutrino-driven wind from a Neutron star, out to ~150 ms, and now we want to turn on a high magnetic field. We have tried B-fields of varying strengths, but if we try a B-field strength that is too high, we find errors generated on the innermost refinement level boundary. We believe if we enlarge the innermost box size ie. CarpetRegrid2::radius_1[6] = 10.5 --> ~19-20, these errors would disappear. But we are having trouble doing this. In our attempt, we activate the trigger thorn with the following settings:
ActiveThorns = "Trigger" Trigger::Trigger_Debug = 1 Trigger::Trigger_Once[0]=1 Trigger::Trigger_Number =1 Trigger::Trigger_Checked_Variable[0]="GRHydro::GRHydro_rho_min" Trigger::Trigger_Reduction [0]="" Trigger::Trigger_Relation [0]="<" Trigger::Trigger_Checked_Value [0]= 1.1 Trigger::Trigger_Reaction [0]="steerparam" Trigger::Trigger_Steered_Parameter_Value [0] = "19.32" Trigger::Trigger_Steered_Parameter_Name [0] = "radius_1[6]" Trigger::Trigger_Steered_Parameter_Thorn [0] = "CarpetRegrid2"
(We use a trivially satisfied trigger condition so that the parameter value is reset immediately upon restart.) Since the CarpetRegrid2 variable "radius_1[6]" is not steerable, we had to modify this to make it such. After turning debug on, we see the following output:
INFO (Trigger): Testing triggers INFO (Trigger): last_checked: -1 INFO (Trigger): trigger nr. 0 fulfilled for GRHydro_rho_min (0.000000<1.100000) INFO (Trigger): Steering parameter INFO (Trigger): Parameter steered
Which supposedly successfully resets the value correctly. We believe that even though this may be the case, the actual grid is not changing. We plot the first 2 boundary levels and show them in the attached file.
There must be interpolation of the second innermost grid onto the innermost grid, and we believe this is not actually handled mid-simulation and thus doesn't not result in the change we expect.
Is there any simple way of changing the inner grid easily? Any help is much appreciated!
[image: image(1).png]
Thanks, Dhruv Desai
Thanks for the tip Roland! I tried this now and am getting new errors. Here is the block in my parameter file now: ActiveThorns = "Trigger" Trigger::Trigger_Debug = 1 Trigger::Trigger_Number =1 Trigger::Trigger_Checked_Variable[0]="GRHydro::GRHydro_rho_min" Trigger::Trigger_Reduction [0]="" Trigger::Trigger_Relation [0]="<" Trigger::Trigger_Checked_Value [0]= 1.1 Trigger::Trigger_Reaction [0]="steerscalar" Trigger::Trigger_Steered_Scalar [0] = "CarpetRegrid2::radii[0]" Trigger::Trigger_Steered_Scalar_Index [0] = 6 Trigger::Trigger_Steered_Scalar_Value [0] = "19.32"
First it crashed because "the parameter CarpetRegrid2::radius_1[6] is not steerable". I then edited CarpetRegrid2 to make radius_1, then got the following error:
while executing schedule bin CCTK_ANALYSIS, routine Trigger::Trigger_Check in thorn Trigger, file /gpfs/fs1/home/d/dsiegel/dhruv/repos/ET_Mayer/Cactus/arrangements/CactusUtils/Trigger/src/trigger.c:404: ->^[[0m steered scalar is of type CCTK_INT
I am confused why it thinks this is an integer quantity, and I am having trouble printing/debugging too. I am not sure how exactly the functions in the trigger thorn determine the 'type' of the cactus quantity, but at least it seems to be finding the right quantity to change.
On Sun, May 1, 2022 at 3:54 PM Roland Haas rhaas@illinois.edu wrote:
Hello Dhruv,
At runtime you have to steer the grid scalars in CarpetRegrid2 rather than the parameters.
See the gallery example for hmns: http://einsteintoolkit.org/gallery/bns/nsnstohmns.par
Trigger::Trigger_Checked_Variable[2]="SphericalSurface::sf_valid[2]" Trigger::Trigger_Reduction [2]="" Trigger::Trigger_Relation [2]=">" Trigger::Trigger_Checked_Value [2]=0. Trigger::Trigger_Reaction [2]="steerscalar" Trigger::Trigger_Steered_Scalar [2] = "CarpetRegrid2::num_levels[0]" # == num_levels_1 Trigger::Trigger_Steered_Scalar_Value[2] = "1"
and for the radii you can look up the Regrid2 docs
http://einsteintoolkit.org/thornguide/Carpet/CarpetRegrid2/documentation.htm...
Trigger::Trigger_Steered_Scalar[triggernum] = "carpetregrid2::radii[center]"
from its interface.ccl (center = 0 in your case for radius_1).
You also must set Trigger::Trigger_Steered_Scalar_Index[triggernum] to the level needed (6 in your case).
Yours, Roland
Hello, I am running a simulation with Daniel Siegel where we use a base level plus 6 refinement levels, like the following: CarpetRegrid2::radius_1[1] = 336.0 # dx/64 CarpetRegrid2::radius_1[2] = 168.0 # dx/64 CarpetRegrid2::radius_1[3] = 84.0 # dx/64 CarpetRegrid2::radius_1[4] = 42.0 # dx/64 CarpetRegrid2::radius_1[5] = 21.0 # dx/64 CarpetRegrid2::radius_1[6] = 10.5 # dx/64
We ran simulations of a neutrino-driven wind from a Neutron star, out to ~150 ms, and now we want to turn on a high magnetic field. We have tried B-fields of varying strengths, but if we try a B-field strength that is too high, we find errors generated on the innermost refinement level boundary. We believe if we enlarge the innermost box size ie. CarpetRegrid2::radius_1[6] = 10.5 --> ~19-20, these errors would disappear. But we are having trouble doing this. In our attempt, we activate the trigger thorn with the following settings:
ActiveThorns = "Trigger" Trigger::Trigger_Debug = 1 Trigger::Trigger_Once[0]=1 Trigger::Trigger_Number =1 Trigger::Trigger_Checked_Variable[0]="GRHydro::GRHydro_rho_min" Trigger::Trigger_Reduction [0]="" Trigger::Trigger_Relation [0]="<" Trigger::Trigger_Checked_Value [0]= 1.1 Trigger::Trigger_Reaction [0]="steerparam" Trigger::Trigger_Steered_Parameter_Value [0] = "19.32" Trigger::Trigger_Steered_Parameter_Name [0] = "radius_1[6]" Trigger::Trigger_Steered_Parameter_Thorn [0] = "CarpetRegrid2"
(We use a trivially satisfied trigger condition so that the parameter value is reset immediately upon restart.) Since the CarpetRegrid2 variable "radius_1[6]" is not steerable, we had to modify this to make it such. After turning debug on, we see the following output:
INFO (Trigger): Testing triggers INFO (Trigger): last_checked: -1 INFO (Trigger): trigger nr. 0 fulfilled for GRHydro_rho_min (0.000000<1.100000) INFO (Trigger): Steering parameter INFO (Trigger): Parameter steered
Which supposedly successfully resets the value correctly. We believe that even though this may be the case, the actual grid is not changing. We plot the first 2 boundary levels and show them in the attached file.
There must be interpolation of the second innermost grid onto the innermost grid, and we believe this is not actually handled mid-simulation and thus doesn't not result in the change we expect.
Is there any simple way of changing the inner grid easily? Any help is much appreciated!
[image: image(1).png]
Thanks, Dhruv Desai
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Hello Dhruv,
while executing schedule bin CCTK_ANALYSIS, routine Trigger::Trigger_Check in thorn Trigger, file /gpfs/fs1/home/d/dsiegel/dhruv/repos/ET_Mayer/Cactus/arrangements/CactusUtils/Trigger/src/trigger.c:404: ->^[[0m steered scalar is of type CCTK_INT
Are you sure you are using an up to date version of the thorn? I cannot find the string "steered scalar is of type" anywhere in Trigger as of git hash a2bc1d4.
Since fa26b80 there is specific support for integers in Trigger.
I am confused why it thinks this is an integer quantity, and I am having trouble printing/debugging too. I am not sure how exactly the functions in the trigger thorn determine the 'type' of the cactus quantity, but at least it seems to be finding the right quantity to change.
This may be a bug in the code. However, as stated above I am not sure which version of Trigger you are using.
Can you verify that indeed it is checked out from (view "git remote -v")
https://bitbucket.org/cactuscode/cactusutils.git
and report the git hash of the current checkout (ie the output of "git log -1"), please?
Yours, Roland
Roland
Dhruv and I discussed. The error was that the parameter file specified a group name ("CarpetRegrid2::radii") instead of a variable name ("CarpetRegrid2::radius"), and `CCTK_TraverseString` got confused, and the respective error doesn't seem to be caught properly. Things seem to be working after specifying the group name.
-erik
On Sat, May 7, 2022 at 11:08 AM Roland Haas rhaas@illinois.edu wrote:
Hello Dhruv,
while executing schedule bin CCTK_ANALYSIS, routine Trigger::Trigger_Check in thorn Trigger, file /gpfs/fs1/home/d/dsiegel/dhruv/repos/ET_Mayer/Cactus/arrangements/CactusUtils/Trigger/src/trigger.c:404: ->^[[0m steered scalar is of type CCTK_INT
Are you sure you are using an up to date version of the thorn? I cannot find the string "steered scalar is of type" anywhere in Trigger as of git hash a2bc1d4.
Since fa26b80 there is specific support for integers in Trigger.
I am confused why it thinks this is an integer quantity, and I am having trouble printing/debugging too. I am not sure how exactly the functions in the trigger thorn determine the 'type' of the cactus quantity, but at least it seems to be finding the right quantity to change.
This may be a bug in the code. However, as stated above I am not sure which version of Trigger you are using.
Can you verify that indeed it is checked out from (view "git remote -v")
https://bitbucket.org/cactuscode/cactusutils.git
and report the git hash of the current checkout (ie the output of "git log -1"), please?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Dhruv, Erik,
Ok. I can see where there are bugs handling TraverseString return values. I will add a bugfix and extend the regression test for Trigger to test steering sclaars and parameters.
Yours, Roland
Roland
Dhruv and I discussed. The error was that the parameter file specified a group name ("CarpetRegrid2::radii") instead of a variable name ("CarpetRegrid2::radius"), and `CCTK_TraverseString` got confused, and the respective error doesn't seem to be caught properly. Things seem to be working after specifying the group name.
-erik
On Sat, May 7, 2022 at 11:08 AM Roland Haas rhaas@illinois.edu wrote:
Hello Dhruv,
while executing schedule bin CCTK_ANALYSIS, routine Trigger::Trigger_Check in thorn Trigger, file /gpfs/fs1/home/d/dsiegel/dhruv/repos/ET_Mayer/Cactus/arrangements/CactusUtils/Trigger/src/trigger.c:404: ->^[[0m steered scalar is of type CCTK_INT
Are you sure you are using an up to date version of the thorn? I cannot find the string "steered scalar is of type" anywhere in Trigger as of git hash a2bc1d4.
Since fa26b80 there is specific support for integers in Trigger.
I am confused why it thinks this is an integer quantity, and I am having trouble printing/debugging too. I am not sure how exactly the functions in the trigger thorn determine the 'type' of the cactus quantity, but at least it seems to be finding the right quantity to change.
This may be a bug in the code. However, as stated above I am not sure which version of Trigger you are using.
Can you verify that indeed it is checked out from (view "git remote -v")
https://urldefense.com/v3/__https://bitbucket.org/cactuscode/cactusutils.git...
and report the git hash of the current checkout (ie the output of "git log -1"), please?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from https://urldefense.com/v3/__http://keys.gnupg.net__;!!DZ3fjg!-UVFEg5nsMLJAHq... . _______________________________________________ Users mailing list Users@einsteintoolkit.org https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinf...
Hello all,
Here's a ticket:
https://bitbucket.org/einsteintoolkit/tickets/issues/2609/trigger-thorn-does...
which fixes (I think) the return code checks (<0 is error, >= 0 is number of variables parsed).
I am still not quite sure how to get the exact error message encountered but there definitely were bugs.
Yours, Roland
Hello Dhruv, Erik,
Ok. I can see where there are bugs handling TraverseString return values. I will add a bugfix and extend the regression test for Trigger to test steering sclaars and parameters.
Yours, Roland
Roland
Dhruv and I discussed. The error was that the parameter file specified a group name ("CarpetRegrid2::radii") instead of a variable name ("CarpetRegrid2::radius"), and `CCTK_TraverseString` got confused, and the respective error doesn't seem to be caught properly. Things seem to be working after specifying the group name.
-erik
On Sat, May 7, 2022 at 11:08 AM Roland Haas rhaas@illinois.edu wrote:
Hello Dhruv,
while executing schedule bin CCTK_ANALYSIS, routine Trigger::Trigger_Check in thorn Trigger, file /gpfs/fs1/home/d/dsiegel/dhruv/repos/ET_Mayer/Cactus/arrangements/CactusUtils/Trigger/src/trigger.c:404: ->^[[0m steered scalar is of type CCTK_INT
Are you sure you are using an up to date version of the thorn? I cannot find the string "steered scalar is of type" anywhere in Trigger as of git hash a2bc1d4.
Since fa26b80 there is specific support for integers in Trigger.
I am confused why it thinks this is an integer quantity, and I am having trouble printing/debugging too. I am not sure how exactly the functions in the trigger thorn determine the 'type' of the cactus quantity, but at least it seems to be finding the right quantity to change.
This may be a bug in the code. However, as stated above I am not sure which version of Trigger you are using.
Can you verify that indeed it is checked out from (view "git remote -v")
https://urldefense.com/v3/__https://bitbucket.org/cactuscode/cactusutils.git...
and report the git hash of the current checkout (ie the output of "git log -1"), please?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from https://urldefense.com/v3/__http://keys.gnupg.net__;!!DZ3fjg!-UVFEg5nsMLJAHq... . _______________________________________________ Users mailing list Users@einsteintoolkit.org https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinf...
users@lists.einsteintoolkit.org
-
Dhruv Desai -
Erik Schnetter -
Roland Haas