[Users] mass estimation of neutron star

[Roland Haas]

Hello Chia-Hui,

https://stellarcollapse.org is your best starting point. Please have a
look at the page for the publications listed there on
https://www.stellarcollapse.org/node/17 in particular for the leakage code:

https://sntheory.org/ottetal2013
https://stellarcollapse.org/cc3dgrmhd

and the code page for the Zelmani codes (Leakage and M1 as well as
version of GRHydro):

https://stellarcollapse.org/Zelmani

where both the newest public version of the leakage and the M1 codes are
available for download.

For the R-process please look at

http://sntheory.org/lippunerroberts2015

and Jonas' skynet code page:

https://bitbucket.org/jlippuner/skynet

Yours,
Roland

> Dear Roland,
> 
> Thanks for your reply.
> 
> For the previous question about r-process, I found a document(https://stellarcollapse.org/media/micra2013/moesta.pdf) saying that GRHydro could consider neutrino leakage. But I have no ideal how to implement it. Is there any suggested way to deal with neutrino leakage with GRHydro (or other thorns) ?
> 
> Thank you.
> 
> Best regards,
> 
> Chia-Hui
> 
> ________________________________
> 寄件者: Roland Haas <rhaas at illinois.edu>
> 寄件日期: 2018年10月2日 下午 09:11:21
> 收件者: 林家暉
> 副本: Einstein Toolkit Users
> 主旨: Re: [Users] mass estimation of neutron star
> 
> Hello Chia-Hui,
> 
> > In addition , I would like to ask question about computation
> > consumption. For the BNS merger (using .par file in the gallery
> > file), it costs about 5000 core hours (48 cores for 100 hours) for
> > the completed simulation (to iteration=15000). Is it reasonable? And
> > is there some way to save the computational resources ?  
> If you want to save overall resources you could reduce the number of
> cores used (assuming you do not run out of memory). For example running
> on 32 cores will make it run slower but not by a factor of 48/32 so
> that the total resources (number-of-cores * hours-used) goes down.
> 
> You could also try reducing (slightly!) the resolution eg by a factor
> of 1.25 which would make the simulation cheaper (but also loose
> significantly in accuracy). Finally you could try and make the
> simulation domain smaller, which safes a bit but not a whole lot
> usually.
> 
> You can also try and see if reducing the amount of output produced
> makes any difference (though that is unlikely). This is the
> outXXX_every parameters and generally everything with an _every in its
> name.
> 
> 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 .



-- 
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 .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20181005/b26e59b4/attachment.bin