Hi,
we are using a version of the EinsteinToolkit of 2017, particularly,
!DEFINE ET_RELEASE = ET_2017_06
so it is not one of the newest versions, but as far as I know in the last releases there has not been updates on the Llama thorn. Although we can try to run with older or newer versions if you think it can help to solve the problem.
Best Regards, Toni.
El mié., 6 mar. 2019 a las 18:29, Zach Etienne (zachetie@gmail.com) escribió:
Hi Antoni,
This is a worrisome finding, thanks for sharing. It would be useful if you would let us know what version of the ET you are using. Further, if you could attempt the simulation with earlier versions of the ET (e.g., the first version with Llama included), it would help to determine if this issue arose due to some recent commit.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 9:40 AM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
my name is Antoni Ramos Buades, I am PhD student in the University of the Balearic Islands working with Sascha Husa. We have been using ET with the Llama thorn to produce waveforms. We have observed in some simulations strange behaviors in the waveforms. For example, I have attached a plot of the amplitude of the psi4 of a non-spinning q1 simulation, for different higher order modes, where you can see that the 22, 32 and 44 show weird spikes. We have rerun this simulation outputting 2D data in the x-y plane. We have plotted the Hamiltonian constraint and made a movie (I cannot attach the movie because its size is 42Mb ) but I can attach some snapshots where you can observe that there seems to be an outburst of noise when the boxes are aligned, and this continues happening in the simulation each time the boxes are aligned with each other. Geraint Pratten is also investigating this issue adding some new parameters in the parameter file (attached to the email) for the carpet mesh refinement like freeze_unaligned_parent_levels, freeze_unaligned_levels, ... and running some tests.
We would like to ask you if somebidy has ever seen this thing happening before and if somebody knows how one could solve this problem, because with the same Carpet settings we have observed that for some configurations (mass ratio and spins) this does not happen, but for others, like the one presented in this email we do. I have additional quantities as a 2D output like the curvature, metric, horizon, ... in case you think they could be used to check something.
Thanks and best regards, Toni. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Toni,
The problem you report seems to be related to the AMR, which is a separate module from Llama. There have been multiple updates to the AMR infrastructure since 2017.
-Zach
* * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 1:42 PM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
we are using a version of the EinsteinToolkit of 2017, particularly,
!DEFINE ET_RELEASE = ET_2017_06
so it is not one of the newest versions, but as far as I know in the last releases there has not been updates on the Llama thorn. Although we can try to run with older or newer versions if you think it can help to solve the problem.
Best Regards, Toni.
El mié., 6 mar. 2019 a las 18:29, Zach Etienne (zachetie@gmail.com) escribió:
Hi Antoni,
This is a worrisome finding, thanks for sharing. It would be useful if you would let us know what version of the ET you are using. Further, if you could attempt the simulation with earlier versions of the ET (e.g., the first version with Llama included), it would help to determine if this issue arose due to some recent commit.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 9:40 AM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
my name is Antoni Ramos Buades, I am PhD student in the University of the Balearic Islands working with Sascha Husa. We have been using ET with the Llama thorn to produce waveforms. We have observed in some simulations strange behaviors in the waveforms. For example, I have attached a plot of the amplitude of the psi4 of a non-spinning q1 simulation, for different higher order modes, where you can see that the 22, 32 and 44 show weird spikes. We have rerun this simulation outputting 2D data in the x-y plane. We have plotted the Hamiltonian constraint and made a movie (I cannot attach the movie because its size is 42Mb ) but I can attach some snapshots where you can observe that there seems to be an outburst of noise when the boxes are aligned, and this continues happening in the simulation each time the boxes are aligned with each other. Geraint Pratten is also investigating this issue adding some new parameters in the parameter file (attached to the email) for the carpet mesh refinement like freeze_unaligned_parent_levels, freeze_unaligned_levels, ... and running some tests.
We would like to ask you if somebidy has ever seen this thing happening before and if somebody knows how one could solve this problem, because with the same Carpet settings we have observed that for some configurations (mass ratio and spins) this does not happen, but for others, like the one presented in this email we do. I have additional quantities as a 2D output like the curvature, metric, horizon, ... in case you think they could be used to check something.
Thanks and best regards, Toni. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
as Zach said, there have been updates to Carpet since then. Though the behaviour is a bit odd.
Carpet will merge refined boxes (eg the two boxes tracking the black holes) if they overlap and form a single large enclosing box. This can lead to a situation where, when the boxes are aligned in x or y, the do not overlap but do when eg they are at 45 degree angels (since they their corners overlap) eg:
xxxxxxxxxxxx ++++++++++++ x x + + x x + + x x + + x x + + xxxxxxxxxxxx ++++++++++++
where everything is fine, vs:
xxxxxxxxxxxx x x x x x x x ++++++++++++ xxxxxxxxxx+x + + + + + + + ++++++++++++
where there is overlap and Carpet will make one large box like so:
********************** * x * * x * * x * * +++++++++++* *xxxxxxxxx+x * * + * * + * * + * **********************
that encloses both black holes.
You will be easily able to see this if you have 2d or 3d output, the load it into eg VisIt, create a slice in the xy plane, then add a "Mesh" plot.
Similar effects can happen if the outer corner of one of the moving boxes (think in 3d here, the outer edge is not on the xy plane but off the xy plane by the height of the moving box) intersects with the inner_sphere radius of Llama.
Right now this is just guess but may expain the observed behaviour if each of the bursts you saw is due to a bit of grid being created or destroyed.
Yours, Roland
Hi Toni,
The problem you report seems to be related to the AMR, which is a separate module from Llama. There have been multiple updates to the AMR infrastructure since 2017.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 1:42 PM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
we are using a version of the EinsteinToolkit of 2017, particularly,
!DEFINE ET_RELEASE = ET_2017_06
so it is not one of the newest versions, but as far as I know in the last releases there has not been updates on the Llama thorn. Although we can try to run with older or newer versions if you think it can help to solve the problem.
Best Regards, Toni.
El mié., 6 mar. 2019 a las 18:29, Zach Etienne (zachetie@gmail.com) escribió:
Hi Antoni,
This is a worrisome finding, thanks for sharing. It would be useful if you would let us know what version of the ET you are using. Further, if you could attempt the simulation with earlier versions of the ET (e.g., the first version with Llama included), it would help to determine if this issue arose due to some recent commit.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 9:40 AM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
my name is Antoni Ramos Buades, I am PhD student in the University of the Balearic Islands working with Sascha Husa. We have been using ET with the Llama thorn to produce waveforms. We have observed in some simulations strange behaviors in the waveforms. For example, I have attached a plot of the amplitude of the psi4 of a non-spinning q1 simulation, for different higher order modes, where you can see that the 22, 32 and 44 show weird spikes. We have rerun this simulation outputting 2D data in the x-y plane. We have plotted the Hamiltonian constraint and made a movie (I cannot attach the movie because its size is 42Mb ) but I can attach some snapshots where you can observe that there seems to be an outburst of noise when the boxes are aligned, and this continues happening in the simulation each time the boxes are aligned with each other. Geraint Pratten is also investigating this issue adding some new parameters in the parameter file (attached to the email) for the carpet mesh refinement like freeze_unaligned_parent_levels, freeze_unaligned_levels, ... and running some tests.
We would like to ask you if somebidy has ever seen this thing happening before and if somebody knows how one could solve this problem, because with the same Carpet settings we have observed that for some configurations (mass ratio and spins) this does not happen, but for others, like the one presented in this email we do. I have additional quantities as a 2D output like the curvature, metric, horizon, ... in case you think they could be used to check something.
Thanks and best regards, Toni. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi,
Roland you are right it is forming and destroying a common box each time the outburst of noise happens. Do you know how one could get rid of this noise, or if there are some parameters of Carpet which one could add to the parameter file to avoid such a behaviour?
Thanks, Toni.
El jue., 7 mar. 2019 a las 3:25, Haas, Roland (rhaas@illinois.edu) escribió:
Hello all,
as Zach said, there have been updates to Carpet since then. Though the behaviour is a bit odd.
Carpet will merge refined boxes (eg the two boxes tracking the black holes) if they overlap and form a single large enclosing box. This can lead to a situation where, when the boxes are aligned in x or y, the do not overlap but do when eg they are at 45 degree angels (since they their corners overlap) eg:
xxxxxxxxxxxx ++++++++++++ x x + + x x + + x x + + x x + + xxxxxxxxxxxx ++++++++++++
where everything is fine, vs:
xxxxxxxxxxxx x x x x x x x ++++++++++++ xxxxxxxxxx+x + + + + + + + ++++++++++++
where there is overlap and Carpet will make one large box like so:
x *x *x *+++++++++++**xxxxxxxxx+x *
+ *+ *+ *
that encloses both black holes.
You will be easily able to see this if you have 2d or 3d output, the load it into eg VisIt, create a slice in the xy plane, then add a "Mesh" plot.
Similar effects can happen if the outer corner of one of the moving boxes (think in 3d here, the outer edge is not on the xy plane but off the xy plane by the height of the moving box) intersects with the inner_sphere radius of Llama.
Right now this is just guess but may expain the observed behaviour if each of the bursts you saw is due to a bit of grid being created or destroyed.
Yours, Roland
Hi Toni,
The problem you report seems to be related to the AMR, which is a separate module from Llama. There have been multiple updates to the AMR infrastructure since 2017.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 1:42 PM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
we are using a version of the EinsteinToolkit of 2017, particularly,
!DEFINE ET_RELEASE = ET_2017_06
so it is not one of the newest versions, but as far as I know in the last releases there has not been updates on the Llama thorn. Although we can try to run with older or newer versions if you think it can help to solve the problem.
Best Regards, Toni.
El mié., 6 mar. 2019 a las 18:29, Zach Etienne (zachetie@gmail.com) escribió:
Hi Antoni,
This is a worrisome finding, thanks for sharing. It would be useful if you would let us know what version of the ET you are using. Further, if you could attempt the simulation with earlier versions of the ET (e.g., the first version with Llama included), it would help to determine if this issue arose due to some recent commit.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 9:40 AM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
my name is Antoni Ramos Buades, I am PhD student in the University of the Balearic Islands working with Sascha Husa. We have been using ET with the Llama thorn to produce waveforms. We have observed in some simulations strange behaviors in the waveforms. For example, I have attached a plot of the amplitude of the psi4 of a non-spinning q1 simulation, for different higher order modes, where you can see that the 22, 32 and 44 show weird spikes. We have rerun this simulation outputting 2D data in the x-y plane. We have plotted the Hamiltonian constraint and made a movie (I cannot attach the movie because its size is 42Mb ) but I can attach some snapshots where you can observe that there seems to be an outburst of noise when the boxes are aligned, and this continues happening in the simulation each time the boxes are aligned with each other. Geraint Pratten is also investigating this issue adding some new parameters in the parameter file (attached to the email) for the carpet mesh refinement like freeze_unaligned_parent_levels, freeze_unaligned_levels, ... and running some tests.
We would like to ask you if somebidy has ever seen this thing happening before and if somebody knows how one could solve this problem, because with the same Carpet settings we have observed that for some configurations (mass ratio and spins) this does not happen, but for others, like the one presented in this email we do. I have additional quantities as a 2D output like the curvature, metric, horizon, ... in case you think they could be used to check something.
Thanks and best regards, Toni. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
Hello Toni,
I am not sure about all the options that arpetRegrid2 offers.
The one that most likely helps is:
CarpetRegrid2::min_fraction = 1.0
which prevents CarpetRegrid2 from ever combining regions.
Yours, Roland
Hi,
Roland you are right it is forming and destroying a common box each time the outburst of noise happens. Do you know how one could get rid of this noise, or if there are some parameters of Carpet which one could add to the parameter file to avoid such a behaviour?
Thanks, Toni.
El jue., 7 mar. 2019 a las 3:25, Haas, Roland (rhaas@illinois.edu) escribió:
Hello all,
as Zach said, there have been updates to Carpet since then. Though the behaviour is a bit odd.
Carpet will merge refined boxes (eg the two boxes tracking the black holes) if they overlap and form a single large enclosing box. This can lead to a situation where, when the boxes are aligned in x or y, the do not overlap but do when eg they are at 45 degree angels (since they their corners overlap) eg:
xxxxxxxxxxxx ++++++++++++ x x + + x x + + x x + + x x + + xxxxxxxxxxxx ++++++++++++
where everything is fine, vs:
xxxxxxxxxxxx x x x x x x x ++++++++++++ xxxxxxxxxx+x + + + + + + + ++++++++++++
where there is overlap and Carpet will make one large box like so:
x *x *x *+++++++++++**xxxxxxxxx+x *
+ *+ *+ *
that encloses both black holes.
You will be easily able to see this if you have 2d or 3d output, the load it into eg VisIt, create a slice in the xy plane, then add a "Mesh" plot.
Similar effects can happen if the outer corner of one of the moving boxes (think in 3d here, the outer edge is not on the xy plane but off the xy plane by the height of the moving box) intersects with the inner_sphere radius of Llama.
Right now this is just guess but may expain the observed behaviour if each of the bursts you saw is due to a bit of grid being created or destroyed.
Yours, Roland
Hi Toni,
The problem you report seems to be related to the AMR, which is a separate module from Llama. There have been multiple updates to the AMR infrastructure since 2017.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 1:42 PM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
we are using a version of the EinsteinToolkit of 2017, particularly,
!DEFINE ET_RELEASE = ET_2017_06
so it is not one of the newest versions, but as far as I know in the last releases there has not been updates on the Llama thorn. Although we can try to run with older or newer versions if you think it can help to solve the problem.
Best Regards, Toni.
El mié., 6 mar. 2019 a las 18:29, Zach Etienne (zachetie@gmail.com) escribió:
Hi Antoni,
This is a worrisome finding, thanks for sharing. It would be useful if you would let us know what version of the ET you are using. Further, if you could attempt the simulation with earlier versions of the ET (e.g., the first version with Llama included), it would help to determine if this issue arose due to some recent commit.
-Zach
Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Wed, Mar 6, 2019 at 9:40 AM Antoni Ramos Buades < antoniramosbuades@gmail.com> wrote:
Hi,
my name is Antoni Ramos Buades, I am PhD student in the University of the Balearic Islands working with Sascha Husa. We have been using ET with the Llama thorn to produce waveforms. We have observed in some simulations strange behaviors in the waveforms. For example, I have attached a plot of the amplitude of the psi4 of a non-spinning q1 simulation, for different higher order modes, where you can see that the 22, 32 and 44 show weird spikes. We have rerun this simulation outputting 2D data in the x-y plane. We have plotted the Hamiltonian constraint and made a movie (I cannot attach the movie because its size is 42Mb ) but I can attach some snapshots where you can observe that there seems to be an outburst of noise when the boxes are aligned, and this continues happening in the simulation each time the boxes are aligned with each other. Geraint Pratten is also investigating this issue adding some new parameters in the parameter file (attached to the email) for the carpet mesh refinement like freeze_unaligned_parent_levels, freeze_unaligned_levels, ... and running some tests.
We would like to ask you if somebidy has ever seen this thing happening before and if somebody knows how one could solve this problem, because with the same Carpet settings we have observed that for some configurations (mass ratio and spins) this does not happen, but for others, like the one presented in this email we do. I have additional quantities as a 2D output like the curvature, metric, horizon, ... in case you think they could be used to check something.
Thanks and best regards, Toni. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
On 7 Mar 2019, at 07:40, Antoni Ramos Buades <antoniramosbuades@gmail.commailto:antoniramosbuades@gmail.com> wrote:
Hi,
Roland you are right it is forming and destroying a common box each time the outburst of noise happens. Do you know how one could get rid of this noise, or if there are some parameters of Carpet which one could add to the parameter file to avoid such a behaviour?
Hi Antoni,
There is this parameter in CarpetRegrid2:
CCTK_REAL min_fraction "Minimum fraction of required refined points that need to be present in a refined region" STEERABLE=always { 0:* :: "" } 0.9
When two boxes overlap, CarpetRegrid2 has to make a decision about whether to use the union of the two boxes, or to replace the two boxes with a single enclosing box. This code is in carpet/CarpetRegrid2/src/property.cchttp://property.cc in the function combine_regions::test_impl. The decision is made based on the number of point in the union of the two boxes, vs the number of points in a single enclosing box. It will leave the regions separate if
min_fraction * combined_size > regions_size
which, with the default of 0.9, means that the number of points in the single enclosing region is greater than 1.11 times the number of points in the original regions. The logic for this is that having lots of regions means lots of faces, edges and corners, and more communication and prolongation, which can affect performance and might also be undesirable due to creating numerical error features such as reflections. On the other hand, the single enclosing region will contain more points, and hence will be more expensive to evolve. min_fraction allows you to decide how many extra points you are willing to evolve, for the sake of having only a single box. If there would be more than 1/min_fraction times the number of points by combining, the code does not combine.
If you set
CarpetRegrid2::min_fraction = 1
then Carpet will never create a single enclosing box, but will always give you a box based on the union of the points in the two boxes.
Ninja'd by Roland. Sigh...
-- Ian Hinder Research Software Engineer University of Manchester, UK
Thanks a lot Zach, Roland and Ian for your comments. We are currently compiling the last version of the EinsteinToolkit and we will make some runs with different values of CarpetRegrid2::min_fraction to check if the noise disappears. We will report you the results in a few days.
Best Regards, Toni.
El jue., 7 mar. 2019 a las 14:47, Ian Hinder (ian.hinder@manchester.ac.uk) escribió:
On 7 Mar 2019, at 07:40, Antoni Ramos Buades antoniramosbuades@gmail.com wrote:
Hi,
Roland you are right it is forming and destroying a common box each time the outburst of noise happens. Do you know how one could get rid of this noise, or if there are some parameters of Carpet which one could add to the parameter file to avoid such a behaviour?
Hi Antoni,
There is this parameter in CarpetRegrid2:
CCTK_REAL min_fraction "Minimum fraction of required refined points that need to be present in a refined region" STEERABLE=always { 0:* :: "" } 0.9
When two boxes overlap, CarpetRegrid2 has to make a decision about whether to use the union of the two boxes, or to replace the two boxes with a single enclosing box. This code is in carpet/CarpetRegrid2/src/ property.cc in the function combine_regions::test_impl. The decision is made based on the number of point in the union of the two boxes, vs the number of points in a single enclosing box. It will leave the regions separate if
min_fraction * combined_size > regions_size
which, with the default of 0.9, means that the number of points in the single enclosing region is greater than 1.11 times the number of points in the original regions. The logic for this is that having lots of regions means lots of faces, edges and corners, and more communication and prolongation, which can affect performance and might also be undesirable due to creating numerical error features such as reflections. On the other hand, the single enclosing region will contain more points, and hence will be more expensive to evolve. min_fraction allows you to decide how many extra points you are willing to evolve, for the sake of having only a single box. If there would be more than 1/min_fraction times the number of points by combining, the code does not combine.
If you set
CarpetRegrid2::min_fraction = 1
then Carpet will never create a single enclosing box, but will always give you a box based on the union of the points in the two boxes.
Ninja'd by Roland. Sigh...
-- Ian Hinder Research Software Engineer University of Manchester, UK
On 7 Mar 2019, at 14:50, Antoni Ramos Buades <antoniramosbuades@gmail.commailto:antoniramosbuades@gmail.com> wrote:
Thanks a lot Zach, Roland and Ian for your comments. We are currently compiling the last version of the EinsteinToolkit and we will make some runs with different values of CarpetRegrid2::min_fraction to check if the noise disappears. We will report you the results in a few days.
Hi Toni,
I suggest to change just one thing at a time; i.e. take the old version of the code that you ran with before, change just this one parameter, and rerun the simulation. If you change too many things at the same time (and you are thinking of making 2 years worth of changes!), the results might be different for many more reasons, and it's hard to reason about the problem.
-- Ian Hinder Research Software Engineer University of Manchester, UK
On Thu, Mar 7, 2019 at 3:56 PM Ian Hinder ian.hinder@manchester.ac.uk wrote:
On 7 Mar 2019, at 14:50, Antoni Ramos Buades antoniramosbuades@gmail.com wrote:
Thanks a lot Zach, Roland and Ian for your comments. We are currently compiling the last version of the EinsteinToolkit and we will make some runs with different values of CarpetRegrid2::min_fraction to check if the noise disappears. We will report you the results in a few days.
Hi Toni,
I suggest to change just one thing at a time; i.e. take the old version of the code that you ran with before, change just this one parameter, and rerun the simulation. If you change too many things at the same time (and you are thinking of making 2 years worth of changes!), the results might be different for many more reasons, and it's hard to reason about the problem.
The plan is to make tests with both the new and old versions of the code. We produced a setup where the problems appears relatively soon, so this won't be too expensive.
Thanks for the quick feedback everybody! cheers, -sascha
-- Ian Hinder Research Software Engineer University of Manchester, UK
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi,
setting the parameter CarpetRegrid2::min_fraction = 1 solves the problem of the noise outburst ( I attach the file waveformMinfraction1.png that you can compare to the older waveforms.png where the noise is present). We have checked the problem with the new version of the EinsteinToolkit which is in the website and with version of 2017 which we were using and the noise disappeared in both. In terms of speed, the run with min_fraction=1 is slightly slower with respect to the older with min_fraction=0.9, but not significantly. I would like to thank again everybody for the quick feedback and help.
Best Regards, Toni.
El jue., 7 mar. 2019 a las 16:00, Sascha Husa (sascha.husa@gmail.com) escribió:
On Thu, Mar 7, 2019 at 3:56 PM Ian Hinder ian.hinder@manchester.ac.uk wrote:
On 7 Mar 2019, at 14:50, Antoni Ramos Buades antoniramosbuades@gmail.com wrote:
Thanks a lot Zach, Roland and Ian for your comments. We are currently compiling the last version of the EinsteinToolkit and we will make some runs with different values of CarpetRegrid2::min_fraction to check if the noise disappears. We will report you the results in a few days.
Hi Toni,
I suggest to change just one thing at a time; i.e. take the old version of the code that you ran with before, change just this one parameter, and rerun the simulation. If you change too many things at the same time (and you are thinking of making 2 years worth of changes!), the results might be different for many more reasons, and it's hard to reason about the problem.
The plan is to make tests with both the new and old versions of the code. We produced a setup where the problems appears relatively soon, so this won't be too expensive.
Thanks for the quick feedback everybody! cheers, -sascha
-- Ian Hinder Research Software Engineer University of Manchester, UK
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
--
Associate Professor (Profesor Contratado Doctor) Departament de Fisica, Universitat de les Illes Balears & Institut d'Estudis Espacials de Catalunya (IEEC) Cra. Valldemossa Km 7.5 / E-07122 Palma de Mallorca/Spain
voice: +34-971-25-9940 fax: +34-971-17-3426 http://grg.uib.cat
On 20 Mar 2019, at 07:52, Antoni Ramos Buades <antoniramosbuades@gmail.commailto:antoniramosbuades@gmail.com> wrote:
Hi,
setting the parameter CarpetRegrid2::min_fraction = 1 solves the problem of the noise outburst ( I attach the file waveformMinfraction1.png that you can compare to the older waveforms.png where the noise is present). We have checked the problem with the new version of the EinsteinToolkit which is in the website and with version of 2017 which we were using and the noise disappeared in both. In terms of speed, the run with min_fraction=1 is slightly slower with respect to the older with min_fraction=0.9, but not significantly. I would like to thank again everybody for the quick feedback and help.
Best Regards, Toni.
Hi Toni,
Good to hear!
-- Ian Hinder Research Software Engineer University of Manchester, UK
Dear all,
I want to solve a spherical problem within a multi patch environment, using Llama and the Thornburg04 coordinates.
For my equations I need several 1st and 2nd spatial derivatives in r direction. The GlobalDerivative thorn (part of Llama) provides a subroutine, that calculates the derivatives for certain directions:
SUBROUTINE globalDiff_gv ( CCTK_POINTER_TO_CONST IN cctkGH, \ CCTK_INT IN dir, \ CCTK_REAL IN ARRAY var, \ CCTK_REAL OUT ARRAY dvar, \ CCTK_REAL IN ARRAY J_dadx, \ CCTK_REAL IN ARRAY J_dbdx, \ CCTK_REAL IN ARRAY J_dcdx, \ CCTK_REAL IN ARRAY J_dady, \ CCTK_REAL IN ARRAY J_dbdy, \ CCTK_REAL IN ARRAY J_dcdy, \ CCTK_REAL IN ARRAY J_dadz, \ CCTK_REAL IN ARRAY J_dbdz, \ CCTK_REAL IN ARRAY J_dcdz, \ CCTK_INT IN table_handle )
However, as far as I could see in the src code this only works for Cartesian coordinates or did I miss something?
Does anyone know if there is a nice way to calculate such derivatives in r direction?
Thanks a lot and best regards,
Severin Frank
Hi Severin,
The globalDiff_gv routine you refer to under the hood calculates the derivatives with respect to whatever coordinates the current patch system is using within the current patch and then uses the Jacobian (passed in) to convert to global (hence the name) cartesian derivatives.
The Thornburg04 coordinate system consists of cubical patch (patch 0) and 6 spherical patches surrounding it (patches 1 to 6)
For the spherical patches the radial coordinate is the 3rd coordinate, so in order to get just radial derivatives you can simply calculate the derivative with respect to the 3rd coordinate. You can either write that yourself or use the calc_dc function used internally in globalDiff_gv. Of course if you use a radial stretch you'll have to take that into account.
Or you can just use the Cartesian derivatives as given by globalDiff_gv and apply the inverse Jacobian to get the radial derivative back. This you'd have to do anyway if you need the radial derivative on the central cubical patch.
Cheers,
Peter
On Thursday 2019-03-21 06:21, Severin Frank wrote:
Date: Thu, 21 Mar 2019 06:21:06 From: Severin Frank severin.frank@uni-tuebingen.de To: users@einsteintoolkit.org Subject: [Users] GlobalDerivative in spherical (multipatch) coordinates
Dear all,
I want to solve a spherical problem within a multi patch environment, using Llama and the Thornburg04 coordinates.
For my equations I need several 1st and 2nd spatial derivatives in r direction. The GlobalDerivative thorn (part of Llama) provides a subroutine, that calculates the derivatives for certain directions:
SUBROUTINE globalDiff_gv ( CCTK_POINTER_TO_CONST IN cctkGH, \ CCTK_INT IN dir, \ CCTK_REAL IN ARRAY var, \ CCTK_REAL OUT ARRAY dvar, \ CCTK_REAL IN ARRAY J_dadx, \ CCTK_REAL IN ARRAY J_dbdx, \ CCTK_REAL IN ARRAY J_dcdx, \ CCTK_REAL IN ARRAY J_dady, \ CCTK_REAL IN ARRAY J_dbdy, \ CCTK_REAL IN ARRAY J_dcdy, \ CCTK_REAL IN ARRAY J_dadz, \ CCTK_REAL IN ARRAY J_dbdz, \ CCTK_REAL IN ARRAY J_dcdz, \ CCTK_INT IN table_handle )
However, as far as I could see in the src code this only works for Cartesian coordinates or did I miss something?
Does anyone know if there is a nice way to calculate such derivatives in r direction?
Thanks a lot and best regards,
Severin Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Antoni Ramos Buades -
Haas, Roland -
Ian Hinder -
Peter Diener -
Sascha Husa -
Severin Frank -
Zach Etienne