Hello Ian, > to something else. This must be a multiple of 4, and can probably go > as low as 20 without the simulation crashing. [Roland: you mentioned > 24 in your email. Did you try 20 and it crashed? I seem to remember > 20 working at one point.] This is a measure of the number of grid > cells across the black holes, so increasing it gives you more cells, > higher resolution, and the run goes more slowly. I did not do a lot of tests. The gallery page https://www.einsteintoolkit.org/gallery/bbh/index.html uses N28 is the command one is supposed to use and suggests 128 cores, and since N24 is used as the "baseline" resolution internally to check what grid to set up, I did not want to go below.
> but this is a technical change to trick NewRad into working with the > spherical grids that we use here. To change the boundary condition > itself, you need to set > > ML_BSSN::rhs_boundary_condition = "NewRad" > > rather than "scalar". Oh right. Thank you. I had not thought of that. Yes that is indeed required. > > The other change Roland made was to change final_time to half its > current value: > > final_time = waveform_length + outermost_detector > -> > final_time = 0.5*(waveform_length + outermost_detector) > > This doesn't seem correct. It is true that final_time is used to set > sphere_outer_radius, but this will not halve the size of the domain. > Further, it will halve the runtime of the simulation, so the > simulation will stop before the BHs have merged. Right again. I think Ian has spend quite a bit more thought on this than I have already and caught a couple of mistakes (one per suggested change I had). Yours, Roland -- 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 .
pgpY4LSLVTOro.pgp
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
