FUKA
|
The isolated NS code was created to test many aspects of the initial data creation such as formalism implementation, initial guess generation, and import into an evolution framework. It has now become a critical piece in generating binary ID that include a NS companion. The codes included here are simply the means for a user to generate an isolated NS and analyze it.
This is an excellent way for a new user to get acquainted with how the FUKAv2 solvers work with ID that requires an EOS.
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_ns.info
solve
for the first timempirun ./bin/Release/solve initial_ns.info
NS_TOTAL_BC.togashi.1.4.0.0.09.<info/dat>
We can deconstruct the name to make it understandable:
NS_TOTAL_BC.
denotes a converged NS solution after the TOTAL_BC stage. This is meant to distinguish the solution from other stages such as the NOROT_BC and boosted NS stage. This also distinguishes it from checkpoints that can be turned on which our saved to file during each iteration of the solvertogashi
denotes the eosfile used in the ID construction1.4.0.
: In this case, we have a 1.4M NS with a dimensionless spin of zero0.09.
: the number of additional spherical nshells
is 0
and 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, EOS parameters, 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 an isolated NS has a mass of 1.4M and 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 NS_TOTAL_BC.togashi.1.4.0.0.09.info
Which results in the following:
The first block contains information related to the numerical space specifically the
[r,theta,phi]
The second block includes the
chi
the dimensionless spin parameteromega
h
Finally, the third block includes
P<x,y,z>
Note:
Diff
noted by the Komar mass is the symmetric difference between the ADM and Komar mass.
Using your favorite text editor, you can open up the initial_ns.info
. We will go through the file, but we'll discuss only the details relevant to the NS case. For details on all the parameters you can see more in Configurator README.
Notes:
initial_ns.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.
The above includes parameters that can be fixed by the user as well as parameters that are automated in the background and should not be changed. Those most relevant to generating ID of interest are
chi
: the dimensionless spin parameter ~[-0.6, 0.6]
madm
: the total gravitational mass is a fixing parameter iff the mb_fixing
control is set to offres
: the final resolution used in each numerical domain (this will be discussed more below)eosfile
: The EOS file containing the cold table or piecewise polytrope to be usedeostype
: specify the use of a cold table Cold_Table
or a piecewise polytrope Cold_PWPoly
h_cut
: (optional) in the event one wants to cut the cold table at a certain specific enthalpy value (default: 0)interpolation_pts
: (optional) number of points to use in order to interpolate a cold table (default: 2000). Not relevant for Cold_PWPoly
For example, if one wanted to change from the default EOS to a Gamma = 2
polytrope, they would set in the config file
eosfile gam2.polytrope
eostype Cold_PWPoly
The other parameters can be ignored.
Within the full Config or the output solutions, Fields
documents the fields that are used in the solver and stored in the dat
file. Changing this has no impact.
For the isolated NS, only the NOROT_BC
and TOTAL_BC
stages are relevant. These will be discussed in the sections below related to these stages. Old stages available in the original v1 solver are since deprecated.
checkpoint
: this will result in checkpoints being saved to file during each solving iteration - mainly helpful for high resolution binary IDsequences
: 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 solution (i.e. the dat
file) is ignored and the solver starts from the most basic initial guessfixed_mb
: **(not fully tested)** toggling this control enables using fixed baryonic mass mb
instead of fixing the gravitational mass madm
solver_max_iterations
: set the number of iterations not to exceedsolver_precision
: Determines what is the maximum precision allowed by the solver that determines whether or not the solution has convergedinitial_resolution
: (optional) by default all solutions are ran at at a default resolution of [9,9,8]
prior to regridding to a higher resolution. In the event one wants to increase the default initial_resolution
, it can be done hereNow that you've generated the simplest case and we have a better understanding of the config file, we can try something more interesting
madm 2.3
chi 0.6
res 11
mpirun ./bin/Release/solve initial_ns.info
Many things will run differently this time! Most notably are the following:
res 11
, the initial solution is always constructed using initial_resolution
first. Currently the default initial resolution is res 9
.TOTAL_BC
stage is reran1. `chi = 0.1` 2. `chi = 0.6`
chi
and madm
is achieved, the solution is interpolated onto a new numerical grid with the desired final resolutionTOTAL_BC
stage is reran to obtain the desired IDNS_TOTAL_BC.togashi.2.3.0.6.0.0.11.info/dat
, however, the other implicit solutions have been saved as well.We can of course verify that the ID matches our expectation using
./bin/Release/reader NS_TOTAL_BC.togashi.2.3.0.6.0.11.info
In initial data generation, the initial setup is the most crucial. When starting the NS solver from scratch, we need to determine an initial guess and what better way than a 1D TOV solution! In this way, a root finder is attempted for the input ADM mass for the specific EOS. Either a solution is found for your input mass (i.e. the input mass is less than the maximum non-rotating TOV mass, Mtov) or the maximum mass is used as the initial guess for the non-rotating solution.
In the event an madm
above Mtov is used with no spin, an error is given.
Once the 1D TOV solution is obtained, this solution is then interpolated onto the scalar fields associated with the low resolution 3D numerical grid.
Now that the initial setup is complete, the first stage to run is the non-rotating stage. In this stage, all equations related to the shift are not taken into account while the fluid and space-time are able to find an equilibrium solution.
With a stable solution to start from, a rotating solution is now found based on the chi
fixing parameter.
For highly spinning NS configurations it has been found to be most reliable to obtain a slowly spinning solution prior to a highly spinning one. Therefore, an initial spin of chi = +/- 0.1
is used before attempting higher spins.
In the event the desired mass is above Mtov, the initial solution is constructed up to the desired chi
using Mtov. Once this solution has been obtained, the ADM mass is updated to the desired ADM mass and only the TOTAL_BC
stage is reran
Once the above procedures are completed for the last stage and the input res
is higher than the initial_resolution
, the low resolution solution is interpolated onto the higher resolution numerical grid and is used as the initial guess before running the last stage again. No additional iterative procedures are required at this point.