- Generated by
1.9.1
|
FUKA
|
A considerable amount of the effort that went into the FUKAv2 solvers for the isolated objects (BH, NS) along with the BBH and BNS solvers built up to constructing this solver. The BHNS has the benefit of suffering from the sensitivity of introducing a NS to a binary setup along with the resolution issues inherent to BH ID. It has presented quite a challenge even with a fairly abundant basis of literature on the topic, but, in the end, has become a work horse within my group.
With that said, if you have taken the time to work through the BBH and BNS v2 solvers, using the BHNS solver will feel quite familiar.
Note: When referring to Mtot below, we will be referring to the sum of the ADM mass of the TOV solution as measured at infinite separation with that of the Christodoulou mass of the companion BH - Mtot := (MADM_MINUS + MCH_PLUS) where plus and minus simply refer to their location on the x-axis.
CMakeLists.txt is the file needed by CMake to compile the codescompile is a symbolic link to the script stored in $HOME_KADATH/build_release to ease compilingsrc directory contains the relevant source files:solve.cpp: the one and done solve codereader.cpp: the reader can provide diagnostics from ID solutions that are computed from the IDsolve for the first timempirun ./bin/Release/solve initial_bhns.infosolve for the first timempirun ./bin/Release/solve initial_bhns.infoBHNS_ECC_RED.togashi.35.0.0.2.8.q1.0.0.09.<info/dat>Note: In the event you have learned about generating FUKAv2 ID in the recommended order as discussed in the FUKAv2 README and you have not disabled centralized_cos; you can look into the solver output to find that the solution of the 1.4M NS generated in the previous runs has been reused.
We can deconstruct the name to make it understandable:
BHNS_ECC_RED. denotes a converged BHNS solution after the eccentricity reduction stage is completed which uses 3.5th order PN estimates for the orbital frequency and radial infall velocity. This is meant to distinguish the solution from earlier stages which will be discussed later. This also distinguishes it from checkpoints that can be turned on which are saved to file during each iteration of the solvertogashi: the leading name of the eosfile35: separation distance in geometric units!0.0.: In this case, both objects are not spinning2.8.q1: the total mass is 2.8 with mass ratio 10.0.09: nshells = 0 for ns1, nshells = 0 for bh2 where the resolution in each domain is 9 collocation points in the radial and theta direction with 8 points in the phi directioninfo: The info file contains all the steering parameters, values used in creating the domain decomposition, stored fields, stages, settings, and controlsdat: The dat file is a binary file that contains the numerical space and the variable fieldsThe default configuration for BHNS has a total mass of 2.8M and is non-spinning. Aside from the diagnostics observed during the solver stage, we can use the reader to verify the ID. This can be done by running:
./bin/Release/reader BHNS_ECC_RED.togashi.35.0.0.2.8.q1.0.2.09.info
Which results in the following:
The first two blocks contain information related to the component objects. These details are covered in the NS README and the BH README. The only additional parameter is the Center_COM. This is the coordinate center of each object when shifted by the "center-of-mass" of the binary or, more specifically, the location of the axis of rotation for the binary that can approximate a quasi-stationary solution.
The third block contains information specifically related to the binary
res: resolution in each numerical domain [r,theta,phi]q: mass ratio such that q <= 1Separation: coordinate separation d [d/Mtot] (d in km)Orbital Omega: orbital frequency of the binaryE_b / mu: Binding energy normalized by the reduced massCOM<x/y>: shift in the coordinates to find a helical killing vectorA-COM<x/y/z>: A numerical calculation of the COM based on the analytical prescription from Osokine+ (REF)Note: The Diff noted by the ADM mass is the symmetric difference between the ADM and Komar mass.
Using your favorite text editor, you can open up the initial_bhns.info. We will go through the file, but we'll discuss only the details relevant to the BHNS case. For details on all the parameters you can read more in the Configurator README.
Notes:
initial_bhns.info. Using old initial data unless for very small changes in chi is inefficient.solve fullto obtain the full Config file. Although useful for development, there is little advantage to using the full Config.
During the various steps to construct the initial binary guess the parameters for each object are copied to construct the isolated solutions as discussed in detail in the respective readmes (NS README, BH README) - the same fixing parameters also apply for the BHNS. The relevant parameters to discuss are
res The resolution shown for the individual compact objects is the highest resolution the isolated dataset will be solved at. This can be important for TOV solutions as the total baryonic mass is sensitive to the resolution. res 11 is recommended for production runs for neutron stars.The fixing parameters most relevant to the binary are
distance: this is in geometric units! It is important to pick something reasonable. A general rule for a binary with a few orbits is distance = 10 * Mtot, however this strongly depends on q and the spins of component objectsouter_shells: This allows for additional shells to be placed near the compactified domain. This can be helpful for more accurate quasi-equilibrium ID at lower resolution, but otherwise can be ignored and left to 0q: this parameter is computed. Changing it by hand does nothingres: global resolution of the binary!adot: (optional) This is the radial infall velocity parameter when performing eccentricity reduction. This will be discussed more in the eccentricity reduction section belowecc_omega: (optional) This is the fixed orbital velocity parameter used when performing eccentricity reduction. This will be discussed more in the eccentricity reduction section belowWithin the full Config or the output solutions, Fields document the fields that are used in the solver and stored in the dat file. Changing this has no impact.
checkpoint: this will result in checkpoints being saved to file during each solving iteration - mainly helpful for high resolution binary ID where walltimes or server failures are a concern prior to a converged solution being obtainedcorot_binary: the objects are no longer fixed based on chi and instead provide a corotating ID solutionfixed_lapse: toggling this control enables a fixed lapse on the horizon - not recommendedsequences: this toggle is enabled by default and essentially tells the driver routine to start from scratch. If this is enabled when attempting to use a previous solution, the previous fields and numerical space (i.e. the dat file) is ignoreduse_pn: toggle whether to always use 3.5PN estimates. It is important to ensure this is off if the user wants to specify their own adot and global_omega parameters by hand (e.g. for iterative eccentricity reduction)resolve: force all implicit compact object solutions to be resolved regardless of an existing previous solutioncentralized_cos: stores all implicit COs into $HOME_KADATH/COssolver_max_iterations: set the number of iterations not to be exceededsolver_precision: Determines what is the maximum precision allowed by the solver that determines whether or not the solution has convergedinitial_resolution: the resolution to use when solving the binary initially before regridding to a higher resolutionNow that you've generated the simplest case and we have a better understanding of the Config file, we can try something more interesting
distance 35res 11ns1 set:madm 1.18chi 0res 11bh2 set:mch 2.42chi 0.52mpirun ./bin/Release/solve initial_bhns.infoThis time around we see the iterative chi increase being done for the NS and BH, but overall the only changes observed are related to the isolated solvers. The binary solver itself is consistent.
This results in the converged dataset of BHNS_ECC_RED.togashi.35.0.0.52.3.6.q0.487603.0.3.11.info/dat, however, the other implicit solutions have been saved as well:
BHNS_TOTAL_BC_FIXED_OMEGA.: is the initial solution after the import of the two isolated solutions have been solved in the binary space for a fixed COM and orbital frequency. The hydro fields are simply rescaled to enforce the specified baryonic mass, but the fluid is not in hydrostatic equilibriumBHNS_TOTAL_BC.: this is the quasi-equilibrium solution in hydrostatic equilibrium with the ADM linear momenta and the orbital frequency being fixed by the force-balance equation for the NS and varying the COMBHNS_ECC_RED.: The final solution is one where the orbital frequency and radial infall velocity is fixed to either 3.5th order PN estimates based on the COM obtained in the TOTAL_BC stage or the values for adot and ecc_omega are used in the case of iterative eccentricity reductionWe can of course verify that the ID matches our expectation using
./bin/Release/reader BHNS_ECC_RED.togashi.35.0.0.52.3.6.q0.487603.0.1.11.info
To generate the initial setup for the binary ID, we first need to make some guesses based on the input ADM masses and the coordinate separation
COM - An estimate of the center-of-mass: this is purely Newtonianglobal_omega - An estimate of the orbital frequency: 3.5th PN estimateOnce these estimates are computed an interface code is ran which
global_omegaAt this point, the binary numerical space and fields are constructed and the isolated solutions are interpolated onto the new grid using the idea of superimposed solutions. Specifically:
decay_limit := w is chosen such that w = distance / 2decay_rate = exp(-(r_NS / w)^4), where r_NS is the coordinate distance from the NSFor example, if we wanted to compute the initial guess for the lapse at a given point x, it would be
lapse(x) = 1. + decay_rate_NS * (lapse_NS(x) - 1.) + decay_rate_BH * (lapse_BH(x) - 1.)
This is then repeated for all fields in all numerical domains, with the compactified domain set to the asymptotic values of the fields, i.e. lapse = psi = 1, log(h) = shift^i = 0.
Once the initial guess has been setup for the BHNS, the first solver stage solves the full XCTS system of equations consistently and all at once using a fixed orbital velocity, however, with regards to a NS source, the matter is simply rescaled to achieve the desired baryonic mass. The reason for this is two fold:
phi needs to be initialized to the binary configurationThe output file from this stage, BHNS_TOTAL_BC_FIXED_OMEGA., can readily be discarded once a solution from a later stage is obtained.
Now with a more stable background, the matter becomes a variable field and is allowed to be solved for consistently in order to obtain a solution in hydrostatic equilibrium. Now global_omega is determined by- and the ADM linear momenta are minimized by- using the force-balance equation and varying the COM.
Note: in the event one wants to later increase the resolution or make iterative changes (e.g. make small changes to the MADM, MB, CHI of one or both stars), it can only be done using the solution from this stage, BHNS_TOTAL_BC.*<info/dat>, as the initial starting point. Reusing the solutions from the hydro-rescaling stage will more often than not cause the solution to diverge or lead to unphysical results in the numerical evolution. Therefore, these solutions can be useful to retain.
In the event the binary resolution was set to something higher than the sequence_setting initial_resolution, the automated increase resolution will take place here and resolve the binary in hydro-static equilibrium. This is very important as increasing the resolution from a solution from a matter-rescaling stage will result in a very inconsistent description of the fluid as it will include numerical errors from the interpolated solution at lower resolution.
Using either 3.5PN estimates or, in the case of iterative eccentricity reduction, ecc_omega and adot from the config file, a final stage of matter rescaling is performed based on the changes introduced by ecc_omega and adot. This is the recommended solution to use for evolutions and it is stored with a filename title of BHNS_ECC_RED.*<info/dat>
1.9.1