[mesa-users] Windows OS

[Robert Farmer]

Hi
So the terminal output doesn't include the time steps at the convergence
problem? So its hard to say what the problem is and the required solution,
so if you could send the output that includes the end steps from your
terminal that will help.

If you look at the last entry in the terminal output, which for your
4M_terminal.txt is normally varcontrol, that tells you what is limiting
your timestep at that point. Which can then be mapped inside the
controls.default file to find the parameter that controls that limiter,
which could help you get through the difficult steps.

Another place to look would be in the 7M_prems_to_AGB test suite and see
whats different between that and the 1M version and see if any of those
controls help.

Rob

On Tue, Jan 12, 2016 at 10:31 PM, Ian Foley <ifoley2008 at gmail.com> wrote:

> I have been using mesa for a few months now. As part of my self-education
> I have been attempting to use the test suites "1M_pre_ms_to_wd" inlist and
> adapting it to run up to 9M and learning a whole lot in the process. I have
> been able to run most of them successfully up to the post_AGB phase with
> the lower masses up to wd. I had to make some changes to the inlists to get
> the larger mass runs to work.
>
> However, strangely, the 4M case always fails during the TP_AGB after about
> 6 thermal pulses and nothing I have done has been able to overcome this. I
> think I am missing the factor which is causing the problem.
>
> This is what I have tried. I have tried various factors for the Reimers
> and Blocker mass loss heuristic. This does not solve the problem and if I
> choose larger numbers like 1 or more for the Blocker wind eta it has the
> effect of smoothing out the thermal pulses. However, the run fails at about
> the same place anyway.
>
> To try to overcome the convergence problem I tried various
> varcontrol_target's from 1d-3 down to 1d-5. Same convergence problem occurs.
>
> I tried setting the mesh_delta_coeff down to 0.3
>  and mesh_dlog_cno_dlogP_extra down to 0.1 so that in one run I was
> creating profiles for every model with over 10,000 zones.
>
> These changes resulted in no improvement with the problem. The run would
> work fine to beyond the sixth thermal pulse as though there was no struggle
> to converge and then run into a convergence  problem which would emerge
> over the space of only perhaps 5 or 10 models with log10(dt/yr) going from
> -2 to -13 plus without being able to converge even once. Mesa seems to
> handle the fact that there is a huge energy production peak in a very thin
> shell for both h1 and he4 very well. That does not seem to be the problem.
> My suspicion is that it has to do with velocity and either diffusion or
> convection. I also tried overshooting parameters in the inlist with no
> effect other than to smooth out the thermal pulses. The behavior has
> symptoms of a term something like x/(a-b) with "a" and "b" nearly the same.
> However, this is just a guess and I have not started to look at the code
> yet. I noticed that in the terminal output the last models showed
> everything normal except the v_div_cs parameter showed strange oscillations
> between negative and positive values in the last few models.
>
> I am sending the email because I am hoping someone out there who knows the
> software a whole lot better than me could point me in the right direction
> and thereby save me a lot of time. I do not understand many of the inlist
> options very well. And just maybe there is someone who already knows about
> this and can give me the answer.
>
> My inlists and terminal output for one of the runs are attached. inlist 4
> also reflects via commented out lines some of the different things I tried.
>
> Kind regards
> ian foley
>
>
>
> On 21 November 2015 at 09:16, Ian Foley <ifoley2008 at gmail.com> wrote:
>
>> I am an uncommon user in that I have downloaded versions of Mesa from way
>> back (2670) and have successfully compiled and run Mesa up to the latest
>> version (7624) under the Windows operating system. Currently I am running
>> Windows 10 with a 64 bit 4 core CPU and 8 GB of internal memory. I am now
>> compiling with gfortran version 4.9.3. I have a windows batch file that
>> does all the compilation using the supplied makefiles, but I have to
>> manually set up the data sub-directory (I used winzip).
>>
>> Naturally, I am not using the mesasdk nor pgplot nor se. Neither am I
>> using the recently introduced maths library in the crlibm subdirectory nor
>> ndiff ( am using the windows fc command). I did manage to compile the
>> makedef90 program, but I had to source the fnmatch code from the internet -
>> I found this program not essential providing the order of the compilation
>> of source files was done manually as mesa was being compiled for the first
>> time. During compilation the tests all ran successfully with outcome
>> matches better than 12 significant figures.
>>
>> I am curious to find out if there are any users out there who are running
>> mesa on windows and perhaps have sourced or created solutions which use the
>> mesasdk, maths library and perhaps have a replacement that does the job of
>> pgplot. I am currently working on the latter, but have only just begun.
>>
>> As a different comment, I was not able to compile Mesa version 4798 and
>> onward in 32 bit environments (earlier than the comments suggest). This was
>> because the nse test failed. When tracking the reason down, I found it
>> failed in the net_initialize source in the setup_reaction_info subroutine
>> where there was a failure at
>> allocate(
>>      >      g% rattab_f1(4*nrattab*num_reactions),
>>      >      stat=ierr)
>>
>> Investigations showed that this statement is trying to create 4*2000*5736
>> bytes, more than 40 MB of memory on the heap. I could not find how to set
>> the heap space with gfortran or how much heap space was available. I tried
>> reducing the size of the nrattab and eventually succeeded in getting the
>> nse test to work, however problems in this allocate reemerged when running
>> star. When I converted to 64 bit environment the compilation worked like a
>> breeze and these problems disappeared. I guessed that 32 bit environments
>> have inadequate heap space available.
>>
>> Any help or thoughts in this area would be most appreciated.
>>
>> Ian
>>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20160114/179820de/attachment.html>