[Mesa-users] Problem with MESA version 10398.

[Ian Foley]

Hi Evan,

Correction. Can increase the swap space in 0.5 GB chunks. The disk image
can be increased to 64 GB and I am only using 31 GB, so that's not the
limit. Will see what increasing the swap space does.

Kind regards
Ian

On 13 April 2018 at 18:38, Ian Foley <ifoley2008 at gmail.com> wrote:

> Hi Evan,
>
> Is that what defines the "swap space" limit setting in docker for windows?
> Currently it is set at 1GB and can only be increased in 1GB chunks. I have
> plenty of hard drive disk space. I will give your suggestion a try and see
> what happens and let you know.
>
> Kind regards
> Ian
>
> On 13 April 2018 at 16:36, Evan Bauer <ebauer at physics.ucsb.edu> wrote:
>
>> Hi Ian,
>>
>> How is your disk usage? Caching the PTEH files can require several GB of
>> disk space, so I wonder if this is a symptom of the container running out
>> of available space to write the cache files?
>>
>> Cheers,
>> Evan
>>
>>
>> > On Apr 12, 2018, at 9:18 PM, Ian Foley via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>> >
>> > Hi,
>> >
>> > I am running docker for windows on Windows 10 Pro on a machine with 4
>> cores and 8GB RAM. I have been working on developing inlists to evolve 1M
>> to 15M stars from pre_ms to end (wd or cc). I have been doing this since
>> version 7624 and always if the run failed MESA would give a reason related
>> to the inlist chosen e.g. timestep limit.
>> >
>> > However, with version 10398, the run has failed quite often by either
>> just hanging leaving screen displays intact, but CPU drops to <10% instead
>> of >50% (program in loop?) or the operating system kills the run. If the
>> process has been killed I am confident that it is not a shortage of memory
>> problem since I increased docker for windows allocation from 3GB to 3.5GB
>> and still had the same problem with the same inlist.
>> >
>> > In all these cases, the run environment was one with a large envelope
>> and very low surface pressure and density and the run was requiring to
>> cache new eosPTEH files.
>> >
>> > I have attached all the files necessary for users to execute a rerun
>> and hopefully reproduce the error and locate the problem. I have also
>> attached all the terminal output (11M,txt) and two files showing the last
>> screens from pgstar. This run hung and it can be seen by looking at the
>> final output in 11M.txt.
>> >
>> > It perhaps should be noted that by changing the inlist to set
>> >
>> >       use_eosPTEH_for_low_density = .false. ! default .true.
>> >       use_eosPTEH_for_high_Z = .false. ! default .true.
>> >
>> > I was able to complete the run with the final outcome being wd - just.
>> The He core was 1.33M.
>> >
>> > Please note that run_star_extras.f does quite a few things whose
>> intention is to try to get a successful run without having to stop mid-way
>> and change parameters. One of the strategies here is to dynamically change
>> var_control according to the number of retries in 10 models and thus allow
>> larger delta changes in parameters and let var_control the size of logdt.
>> This usually works, but can fail when there are a large number of retries
>> in 10 models and var_control does not adapt fast enough.
>> >
>> > Kind regards
>> > Ian
>> >
>> >
>> > <11M.txt><history_columns.list><ian40r.net><inlist_11M.0><
>> profile_columns.list><run_star_extras.f><grid6_001290.png><
>> profile_Panels3_001290.png>_________________________________
>> ______________
>> > mesa-users at lists.mesastar.org
>> > https://lists.mesastar.org/mailman/listinfo/mesa-users
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180413/96531a30/attachment.html>