Hello Chia-Hui,
I do not quite understand what causes ,in your example,
CarpetRegrid2::position_x_1 = 42. CarpetRegrid2::position_x_2 = -17
to become fail.
This has to do with the way that the thorn GRHydro_Analysis that looks for the location of the star works. It first determines the location on the grid with the largest density, then it computes a center of mass integral in a region around that point. This computed center of mass if used as the location of the star and to move boxes. There is code in thorn NSTracker that uses this single found location and moves two refined regions to (x,y,z) and (-x,-y,z) where (x,y,z) is the found location of the star.
There are two reasons why this does not work well with unequal masses:
1. it only looks for a single star and bases that star's location on the highest density 2. NSTracker makes the hard-coded assumption that the two regions that cover the star are mirror immages of each other
In your case since the star at -17 (always assuming you actually have set up a grid that has no symmetries) is the heavier one (since it is closer to the center of rotation) and thus has the higher central density, therefore GRHydro_Analysis will use it as the star to track and thus will find the star location to be (-17,0,0) when it looks for the star.
In my case, if the initial location of the binary star is (-34.59 km , 45.41 km) , I should set
CarpetRegrid2::position_x_1 = -34.59/1.48=-23.37 CarpetRegrid2::position_x_2 = 45.41/1.48=30.68
right?
Yes that is correct.
Would this soon be set to (-23.37,23.37)? Because the mass difference is not so much, I am wondering whether there exists some maximum value of mass ratio which can tolerate small mass difference.
By the way ,the link https://trac.einsteintoolkit.org/ticket/1974 seems not work. I would like to check it up.
Thank you for pointing this out. It seems that there is an endless redirection loop in the trac website already for https://trac.einsteintoolkit.org
Yours, Roland