<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear Roland,</p>
<p>Thanks for your reply.</p>
<p>For the previous question about r-process, I found a document(<a href="https://stellarcollapse.org/media/micra2013/moesta.pdf" class="x_OWAAutoLink" id="LPlnk793368">https://stellarcollapse.org/media/micra2013/moesta.pdf</a>) 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) ?</p>
<p>Thank you.</p>
<p>Best regards,</p>
<p>Chia-Hui</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>寄件者:</b> Roland Haas <rhaas@illinois.edu><br>
<b>寄件日期:</b> 2018年10月2日 下午 09:11:21<br>
<b>收件者:</b> 林家暉<br>
<b>副本:</b> Einstein Toolkit Users<br>
<b>主旨:</b> Re: [Users] mass estimation of neutron star</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hello Chia-Hui,<br>
<br>
> In addition , I would like to ask question about computation<br>
> consumption. For the BNS merger (using .par file in the gallery<br>
> file), it costs about 5000 core hours (48 cores for 100 hours) for<br>
> the completed simulation (to iteration=15000). Is it reasonable? And<br>
> is there some way to save the computational resources ?<br>
If you want to save overall resources you could reduce the number of<br>
cores used (assuming you do not run out of memory). For example running<br>
on 32 cores will make it run slower but not by a factor of 48/32 so<br>
that the total resources (number-of-cores * hours-used) goes down.<br>
<br>
You could also try reducing (slightly!) the resolution eg by a factor<br>
of 1.25 which would make the simulation cheaper (but also loose<br>
significantly in accuracy). Finally you could try and make the<br>
simulation domain smaller, which safes a bit but not a whole lot<br>
usually.<br>
<br>
You can also try and see if reducing the amount of output produced<br>
makes any difference (though that is unlikely). This is the<br>
outXXX_every parameters and generally everything with an _every in its<br>
name.<br>
<br>
Yours,<br>
Roland<br>
<br>
-- <br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu">http://pgp.mit.edu</a> .<br>
</div>
</span></font>
</body>
</html>