Hello Everyone,
I'm working on binary black hole mergers with large mass ratio (20:1 or more). By using higher refinement level, I have been able to resolve the smaller BH, but it doesn't remain resolved even for a single time step.
So far, I have tried changing the CarpetRegrid2::regrid_every and AHFinderDirect::find_every to as small as 1. Could someone please help me where I'm going wrong? I'm sure there are other problems too with my parameter file. I have attached the par file if anyone would be kind enough to give me further suggestions for this problem.
Thanks, Rahul
On Mon, Jun 06, 2016 at 12:41:35PM -0400, rahul kashyap wrote:
I'm working on binary black hole mergers with large mass ratio (20:1 or more). By using higher refinement level, I have been able to resolve the smaller BH, but it doesn't remain resolved even for a single time step.
Hi,
Thanks for contacting us. I am not that familiar with that particular type of simulation (bbh with that mass ratio), but I try to give a best guess. Please everyone: if you disagree, say so. :)
It would be interesting to know what exactly you mean with 'doesn't remain resolved'. Assuming that the resolution is high enough, one thing I would expect a simulation like this to use is some kind of position-dependent gauge condition. The reason is that one thing the gauge mostly does is (loosely speaking) to "prevent the grid points from falling into the black hole, or to come out of it". In your simulation you see this as a black hole that gets 'larger or smaller' without changing its mass a lot. The best parameter values that determine how much the grid points are "pushed out" depend on the black hole mass. Since you mass ratio is quite large, I would expect the optimal parameter to be quite different for the two black holes.
There are groups that did evolve BBHs with even higher mass ratios than this - not using the exact same code, but the same methods. They should have much more experience. Anyone - you know whom I mean ...?
Frank
Thanks for the reply. My apologies that I'm not completely familiar many of the physical and numerical issues while simulating bbh. I have experience in AMR astrophysical simulations.
When I do the bbh simulation of ratio around 1, it evolves perfectly fine. With higher mass ratio, the smaller BH just becomes bigger and blows up. I'm assuming this as a problem of refinement.
My naive picture was that the grid is created adaptively at every n time step(a parameter) based on lapse values. After locating the horizon, dynamic variables are updated in the outside region only. So, the problem remains with locating the horizon often enough and refining to the appropriate level so that at least 4-5 cells remains across a BH. Please correct me, if I'm off by any big misunderstanding.
Thanks again, -rahul
On Mon, Jun 6, 2016 at 4:22 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Mon, Jun 06, 2016 at 12:41:35PM -0400, rahul kashyap wrote:
I'm working on binary black hole mergers with large mass ratio (20:1 or more). By using higher refinement level, I have been able to resolve the smaller BH, but it doesn't remain resolved even for a single time step.
Hi,
Thanks for contacting us. I am not that familiar with that particular type of simulation (bbh with that mass ratio), but I try to give a best guess. Please everyone: if you disagree, say so. :)
It would be interesting to know what exactly you mean with 'doesn't remain resolved'. Assuming that the resolution is high enough, one thing I would expect a simulation like this to use is some kind of position-dependent gauge condition. The reason is that one thing the gauge mostly does is (loosely speaking) to "prevent the grid points from falling into the black hole, or to come out of it". In your simulation you see this as a black hole that gets 'larger or smaller' without changing its mass a lot. The best parameter values that determine how much the grid points are "pushed out" depend on the black hole mass. Since you mass ratio is quite large, I would expect the optimal parameter to be quite different for the two black holes.
There are groups that did evolve BBHs with even higher mass ratios than this - not using the exact same code, but the same methods. They should have much more experience. Anyone - you know whom I mean ...?
Frank
On Mon, Jun 06, 2016 at 06:50:04PM -0400, rahul kashyap wrote:
Thanks for the reply. My apologies that I'm not completely familiar many of the physical and numerical issues while simulating bbh. I have experience in AMR astrophysical simulations.
No need to apologize.
When I do the bbh simulation of ratio around 1, it evolves perfectly fine. With higher mass ratio, the smaller BH just becomes bigger and blows up. I'm assuming this as a problem of refinement.
It is not. It looks like what I described earlier: your gauge conditions, in particular the shift condition, isn't well suited for the small black hole. Grid points are "falling in", making it appear growing on the computational grid. You may try to play with the values such that the small black hole evolves fine (you can try that with a simulation of only a small black hole of that size), but then you might find that the large black hole "vanishes from the grid" because grid points there are pushed out too much. If this is the case, you might need position-dependent values.
Frank
Hi,
This issue is discussed for example in
http://arxiv.org/abs/1003.4681
where a non-constant damping in the gamma driver shift is presented to handle unequal mass binaries. As far as I remember there may also be later papers with further improvements to the method.
Cheers,
Peter
On Tuesday 2016-06-07 01:00, Frank Loeffler wrote:
Date: Tue, 7 Jun 2016 01:00:59 From: Frank Loeffler knarf@cct.lsu.edu To: rahul kashyap rahulkashyap411@gmail.com Cc: Einstein Toolkit Users users@einsteintoolkit.org Subject: Re: [Users] Resolving two BH
On Mon, Jun 06, 2016 at 06:50:04PM -0400, rahul kashyap wrote:
Thanks for the reply. My apologies that I'm not completely familiar many of the physical and numerical issues while simulating bbh. I have experience in AMR astrophysical simulations.
No need to apologize.
When I do the bbh simulation of ratio around 1, it evolves perfectly fine. With higher mass ratio, the smaller BH just becomes bigger and blows up. I'm assuming this as a problem of refinement.
It is not. It looks like what I described earlier: your gauge conditions, in particular the shift condition, isn't well suited for the small black hole. Grid points are "falling in", making it appear growing on the computational grid. You may try to play with the values such that the small black hole evolves fine (you can try that with a simulation of only a small black hole of that size), but then you might find that the large black hole "vanishes from the grid" because grid points there are pushed out too much. If this is the case, you might need position-dependent values.
Frank
Hello,
Does this paper come with access to a par file that will show how to set the dynamic shift?
I need some help as well in setting up a run with two unequal mass black holes, for an undergraduate visualization project. My understanding is that the initial conditions are set with the parameters given in the TwoPunctures thorn. For example, if I want the first black hole to be equal with the mass of the sun, and the second, 10 times the mass of the sun, I do something like this?
TwoPunctures::par_m_plus = 1.5 TwoPunctures::par_m_minus = 15
The last thing I need to set is the velocity for each hole, If I want each of them to move at 1/3 c tangential velocity? I’m assuming I need to set:
TwoPunctures::par_P_plus [1] = +0.45 TwoPunctures::par_P_minus[1] = -4.5
Is this correct? And one more important thing: if I want the distance between them to be for example 150, how do I set this? I see a parameter par_b which gives the x coordinate of the m+ puncture, but I’m not clear if this is what I need to set, and how.
All the other parameters I am assuming are to be kept the way they are. In Rahul’s parameter file I do not see the PunctureTracker thorn activated. I do want to know the position of the back holes on the grid, and the distance between them at each step of the evolution. Do I need to activate PunctureTracker? What output do I need for this?
Thank you, Maria
On 6/7/16, 10:13 AM, "users-bounces@einsteintoolkit.org on behalf of Peter Diener" <users-bounces@einsteintoolkit.org on behalf of diener@cct.lsu.edu> wrote:
Hi,
This issue is discussed for example in
http://arxiv.org/abs/1003.4681
where a non-constant damping in the gamma driver shift is presented to handle unequal mass binaries. As far as I remember there may also be later papers with further improvements to the method.
Cheers,
Peter
On Tuesday 2016-06-07 01:00, Frank Loeffler wrote:
Date: Tue, 7 Jun 2016 01:00:59 From: Frank Loeffler knarf@cct.lsu.edu To: rahul kashyap rahulkashyap411@gmail.com Cc: Einstein Toolkit Users users@einsteintoolkit.org Subject: Re: [Users] Resolving two BH
On Mon, Jun 06, 2016 at 06:50:04PM -0400, rahul kashyap wrote:
Thanks for the reply. My apologies that I'm not completely familiar many of the physical and numerical issues while simulating bbh. I have experience in AMR astrophysical simulations.
No need to apologize.
When I do the bbh simulation of ratio around 1, it evolves perfectly fine. With higher mass ratio, the smaller BH just becomes bigger and blows up. I'm assuming this as a problem of refinement.
It is not. It looks like what I described earlier: your gauge conditions, in particular the shift condition, isn't well suited for the small black hole. Grid points are "falling in", making it appear growing on the computational grid. You may try to play with the values such that the small black hole evolves fine (you can try that with a simulation of only a small black hole of that size), but then you might find that the large black hole "vanishes from the grid" because grid points there are pushed out too much. If this is the case, you might need position-dependent values.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Maria,
On Tuesday 2016-06-07 10:02, Hamilton, Maria wrote:
Date: Tue, 7 Jun 2016 10:02:36 From: "Hamilton, Maria" babiuc@marshall.edu To: Peter Diener diener@cct.lsu.edu, Frank Loeffler knarf@cct.lsu.edu Cc: Einstein Toolkit Users users@einsteintoolkit.org Subject: Re: [Users] Resolving two BH
Hello,
Does this paper come with access to a par file that will show how to set the dynamic shift?
No it doesn't. That paper was based on the Jena groups BAM code and these features have not yet been implemented in McLachlan.
I need some help as well in setting up a run with two unequal mass black holes, for an undergraduate visualization project. My understanding is that the initial conditions are set with the parameters given in the TwoPunctures thorn. For example, if I want the first black hole to be equal with the mass of the sun, and the second, 10 times the mass of the sun, I do something like this?
TwoPunctures::par_m_plus = 1.5 TwoPunctures::par_m_minus = 15
The code uses units so G=c=1 so you can get mass you want. But yes, this will give you a mass ratio of 10. Note however, that if you want this to be the physical masses, you have to set
TwoPunctures::give_bare_mass = no
as well. Otherwise these will be the bare mass parameters given as input to the elliptical solve, and the actual physical masses after the solve might be a little bit different. One comment: I usually preferred to have the total mass be 1.0 in order to make grid setup as well as analysis simpler between runs with different mass ratio. So I would use
TwoPunctures::par_m_plus = 0.09090909090909 TwoPunctures::par_m_minus = 0.9090909090909
But That is a matter of taste of course.
The last thing I need to set is the velocity for each hole, If I want each of them to move at 1/3 c tangential velocity? I’m assuming I need to set:
TwoPunctures::par_P_plus [1] = +0.45 TwoPunctures::par_P_minus[1] = -4.5
You most likely want to do the simulation in the rest frame, where the total momentum is 0. Otherwise your black hole system will drift away from the system. So the larger black hole will move 10 times slower than the small black hole. How big a velocity you want depends on exactly what kind of system you want to evolve. Do you want a hyperbolic flyby, an elliptical orbit or a quasi-circular orbit?
Is this correct? And one more important thing: if I want the distance between them to be for example 150, how do I set this? I see a parameter par_b which gives the x coordinate of the m+ puncture, but I’m not clear if this is what I need to set, and how.
Yes, par_b gives the x-coordinate of the m+ puncture. By default the m- puncture will then be at -par_b (on the x-axis). So par_b is 1/2 the coordinate separation of the punctures. There is in addition a parameter center_offset that allow you to add an offset to the initial position. Again the choice of the separation and of the momenta goes hand in hand to determine what kind of orbit you'll get.
All the other parameters I am assuming are to be kept the way they are. In Rahul’s parameter file I do not see the PunctureTracker thorn activated. I do want to know the position of the back holes on the grid, and the distance between them at each step of the evolution. Do I need to activate PunctureTracker? What output do I need for this?
As far as I remember you just need to activate PunctureTracker and then set a few parameters to activate tracking as well as setting the initial puncture positions consistently with the TwoPuncture parameters.
And as far as I remember PunctureTracker keeps track of the punctures in Cactus grid scalars and you'd just need to request output for those.
Thank you, Maria
Cheers,
Peter
On 6/7/16, 10:13 AM, "users-bounces@einsteintoolkit.org on behalf of Peter Diener" <users-bounces@einsteintoolkit.org on behalf of diener@cct.lsu.edu> wrote:
Hi,
This issue is discussed for example in
http://arxiv.org/abs/1003.4681
where a non-constant damping in the gamma driver shift is presented to handle unequal mass binaries. As far as I remember there may also be later papers with further improvements to the method.
Cheers,
Peter
On Tuesday 2016-06-07 01:00, Frank Loeffler wrote:
Date: Tue, 7 Jun 2016 01:00:59 From: Frank Loeffler knarf@cct.lsu.edu To: rahul kashyap rahulkashyap411@gmail.com Cc: Einstein Toolkit Users users@einsteintoolkit.org Subject: Re: [Users] Resolving two BH
On Mon, Jun 06, 2016 at 06:50:04PM -0400, rahul kashyap wrote:
Thanks for the reply. My apologies that I'm not completely familiar many of the physical and numerical issues while simulating bbh. I have experience in AMR astrophysical simulations.
No need to apologize.
When I do the bbh simulation of ratio around 1, it evolves perfectly fine. With higher mass ratio, the smaller BH just becomes bigger and blows up. I'm assuming this as a problem of refinement.
It is not. It looks like what I described earlier: your gauge conditions, in particular the shift condition, isn't well suited for the small black hole. Grid points are "falling in", making it appear growing on the computational grid. You may try to play with the values such that the small black hole evolves fine (you can try that with a simulation of only a small black hole of that size), but then you might find that the large black hole "vanishes from the grid" because grid points there are pushed out too much. If this is the case, you might need position-dependent values.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 8 Jun 2016, at 17:22, Peter Diener diener@cct.lsu.edu wrote:
Hi Maria,
On Tuesday 2016-06-07 10:02, Hamilton, Maria wrote:
Date: Tue, 7 Jun 2016 10:02:36 From: "Hamilton, Maria" babiuc@marshall.edu To: Peter Diener diener@cct.lsu.edu, Frank Loeffler knarf@cct.lsu.edu Cc: Einstein Toolkit Users users@einsteintoolkit.org Subject: Re: [Users] Resolving two BH
Hello,
Does this paper come with access to a par file that will show how to set the dynamic shift?
No it doesn't. That paper was based on the Jena groups BAM code and these features have not yet been implemented in McLachlan.
I need some help as well in setting up a run with two unequal mass black holes, for an undergraduate visualization project. My understanding is that the initial conditions are set with the parameters given in the TwoPunctures thorn. For example, if I want the first black hole to be equal with the mass of the sun, and the second, 10 times the mass of the sun, I do something like this?
TwoPunctures::par_m_plus = 1.5 TwoPunctures::par_m_minus = 15
The code uses units so G=c=1 so you can get mass you want. But yes, this will give you a mass ratio of 10. Note however, that if you want this to be the physical masses, you have to set
TwoPunctures::give_bare_mass = no
as well. Otherwise these will be the bare mass parameters given as input to the elliptical solve, and the actual physical masses after the solve might be a little bit different. One comment: I usually preferred to have the total mass be 1.0 in order to make grid setup as well as analysis simpler between runs with different mass ratio. So I would use
TwoPunctures::par_m_plus = 0.09090909090909 TwoPunctures::par_m_minus = 0.9090909090909
But That is a matter of taste of course.
par_m_plus and par_m_minus are always the bare masses. give_bare_mass = yes means that they are used as the bare masses. give_bare_mass = no mean that TwoPunctures will iterate to find them . You need to set give_bare_mass = no, so that they are ignored, and then set
TwoPunctures::target_M_plus = 0.09090909090909 TwoPunctures::target_M_minus = 0.9090909090909
These are the target masses that you want, and TwoPunctures will then iterate to find the bare masses needed to get these target masses.
The last thing I need to set is the velocity for each hole, If I want each of them to move at 1/3 c tangential velocity? I’m assuming I need to set:
TwoPunctures::par_P_plus [1] = +0.45 TwoPunctures::par_P_minus[1] = -4.5
You most likely want to do the simulation in the rest frame, where the total momentum is 0. Otherwise your black hole system will drift away from the system. So the larger black hole will move 10 times slower than the small black hole. How big a velocity you want depends on exactly what kind of system you want to evolve. Do you want a hyperbolic flyby, an elliptical orbit or a quasi-circular orbit?
If you want a circular orbit, then you need to work out the correct tangential momentum for the separation you are using, otherwise you will in general get an eccentric orbit. Note that these are momenta, not velocities. This can be done using PN, though for mass ratios of 1:20 I doubt that will be accurate. Typically, you need to evolve with an initial guess, measure the eccentricity, then update your initial parameters to reduce that eccentricity. It's a pain.
Is this correct? And one more important thing: if I want the distance between them to be for example 150, how do I set this? I see a parameter par_b which gives the x coordinate of the m+ puncture, but I’m not clear if this is what I need to set, and how.
Yes, par_b gives the x-coordinate of the m+ puncture. By default the m- puncture will then be at -par_b (on the x-axis). So par_b is 1/2 the coordinate separation of the punctures. There is in addition a parameter center_offset that allow you to add an offset to the initial position. Again the choice of the separation and of the momenta goes hand in hand to determine what kind of orbit you'll get.
All the other parameters I am assuming are to be kept the way they are. In Rahul’s parameter file I do not see the PunctureTracker thorn activated. I do want to know the position of the back holes on the grid, and the distance between them at each step of the evolution. Do I need to activate PunctureTracker? What output do I need for this?
As far as I remember you just need to activate PunctureTracker and then set a few parameters to activate tracking as well as setting the initial puncture positions consistently with the TwoPuncture parameters.
And as far as I remember PunctureTracker keeps track of the punctures in Cactus grid scalars and you'd just need to request output for those.
And finally, please note that q = 20 is well beyond what most experienced NR groups are comfortable evolving. q=10 is also very challenging.
users@lists.einsteintoolkit.org
-
Frank Loeffler -
Hamilton, Maria -
Ian Hinder -
Peter Diener -
rahul kashyap