[Mesa-users] MESA installation data folder

[amber lauer]

The cache files save time during runtime, right? In that case I'm not
really concered about turning them off, since the size of the installation
is only a concern when users are downloading the VM, not once they've
installed. At the suggestion of Frank Timmes I'm going to increase the
virtual drive size to 50gb. Since it is dynamically allocated it will still
only be as large as the actual files on the virtual drive, minus any gains
from compression (I'm using .7z since I believe that is the most efficient
algorithm at present). I had a request to increase it to 100gb, but I don't
think that's feasible for all users. Also, if they're using MESA enough
that they've generated 10's of GB of run files, it's probably time to start
thinking about a local installation.

The use case I envision for this is beginners who aren't ready to jump into
linux full time or students in a class who either have trouble with the
installation and need a working version fast, or those who *only* need it
for a class and have no reason to commit to linux full time (or buy a mac).

On Sat, Mar 31, 2018 at 7:33 AM, Rob Farmer <r.j.farmer at uva.nl> wrote:

> There are some easy steps to remove unneeded files from mesa:
>
> rm -rf data/*/cache/*  # > 1gb
> You can also set use_cache=.false. in star/private/star/private_def.f90
> to turn of making cache files at all
>
> Lots if stuff we don't need after installation:
> rm -rf */{*.tar.*,*.txz,*.tbz} # 2gb
> rm -rf .svn #2.5gb
> rm -rf */make/* #62mb
> rm -rf *.rb # small
> rm -rf */data #small
> rm -rf eos/*_builder #200mb
> rm -rf */preprocessor #64mb
>
> thats at least ~5.5Gb saving
>
> Rob
>
>
> On 31 March 2018 at 06:11, amber lauer via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> Evan, have you updated the docker container to the newest version? If so
>> what effects has this had on the size of the container? I'm just thinking
>> about distribution considerations.
>>
>> Maybe there's a way to hold off on populating the tables until the end
>> user installs the VM/container. I'll have to see how small I can compress
>> the VM once it's complete, to see if I need to pursue this option.
>>
>> On Fri, Mar 30, 2018, 10:42 PM Evan Bauer <ebauer at physics.ucsb.edu>
>> wrote:
>>
>>> Hi Amber,
>>>
>>> Yes, I believe this is normal. Most of the size increase is due to the
>>> extensive new EOS tables that are shipped for the PTEH and ELM options, as
>>> you can see from the eosDT_data entry that you posted.
>>>
>>> Evan
>>>
>>>
>>> > On Mar 30, 2018, at 7:06 PM, Francis Timmes via Mesa-users <
>>> mesa-users at lists.mesastar.org> wrote:
>>> >
>>> >> My total folder size is ~18gb now, FYI.
>>> >> Is this normal?
>>> >
>>> > yes. mine is ~20gb but i have some cache stuff in there.
>>> > maybe go to 50gb on the virtual to allow room to run?
>>> >
>>> > fxt
>>> >
>>> >
>>> >
>>> >
>>> >> On Mar 30, 2018, at 6:47 PM, amber lauer via Mesa-users <
>>> mesa-users at lists.mesastar.org> wrote:
>>> >>
>>> >> My total folder size is ~18gb now, FYI. I just redownloaded it and
>>> compiled again as a test with the same result.
>>> >>
>>> >> On Fri, Mar 30, 2018 at 9:46 PM, amber lauer <
>>> amber.lauer at tunl.duke.edu> wrote:
>>> >> Looking back at version 9793 I see that the entire installation takes
>>> about 5.7gb. I recently upgraded to 10398 via svn (the folder is about 2gb
>>> larger via this method than downloading the zip, but it's way quicker).
>>> >>
>>> >> Here's an output of the folder sizes for /mesa/data:
>>> >>
>>> >> 64K  ./rates_data/rate_tables
>>> >> 21M  ./rates_data/suzuki
>>> >> 175M ./rates_data/cache
>>> >> 250M ./rates_data
>>> >> 20M  ./star_data/zams_models
>>> >> 18M  ./star_data/white_dwarf_models
>>> >> 76K  ./star_data/plot_info
>>> >> 4.0K ./star_data/planet_models_without_cores
>>> >> 4.0K ./star_data/planet_models_with_inert_cores
>>> >> 2.0M ./star_data/very_low_mass_grey_models
>>> >> 2.0M ./star_data/very_low_mass_COND_tau100_models
>>> >> 392K ./star_data/very_low_mass_COND_tau1_models
>>> >> 44M  ./star_data
>>> >> 332K ./net_data/nets
>>> >> 340K ./net_data
>>> >> 2.8M ./chem_data
>>> >> 760K ./colors_data
>>> >> 2.7G ./eosDT_data/cache
>>> >> 12G  ./eosDT_data
>>> >> 283M ./eosPT_data/cache
>>> >> 525M ./eosPT_data
>>> >> 53M  ./kap_data/cache
>>> >> 491M ./kap_data
>>> >> 336M ./ionization_data/cache
>>> >> 431M ./ionization_data
>>> >> 1.1M ./atm_data
>>> >>
>>> >> Is this normal? I specifically ask this because I'll have to redo the
>>> VMESA virtual machine because I only designed it to have a 20gb hdd.
>>> >>
>>> >> --
>>> >> Amber Lauer
>>> >> Postdoctoral Researcher
>>> >> Triangle University Nuclear Lab
>>> >> Duke University
>>> >> amber.lauer at tunl.duke.edu
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amber Lauer
>>> >> Postdoctoral Researcher
>>> >> Triangle University Nuclear Lab
>>> >> Duke University
>>> >> amber.lauer at tunl.duke.edu
>>> >> _______________________________________________
>>> >> mesa-users at lists.mesastar.org
>>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.m
>>> esastar.org_mailman_listinfo_mesa-2Dusers&d=DwIFAg&c=imBPVzF
>>> 25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=IZ3U2LUL6yhDK-Uf8F_
>>> eU9W85o61MM43boq-nVwHt38&m=Y1h3ERzFuyyrZqMVfSZPPnKHjrPius4xa
>>> R6YFeyZo70&s=mLeh8MfbUIA3a_yzaiuqc8Cnrf69TAPIK7iocZaNqVk&e=
>>> >
>>> > _______________________________________________
>>> > mesa-users at lists.mesastar.org
>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.m
>>> esastar.org_mailman_listinfo_mesa-2Dusers&d=DwIFAg&c=imBPVzF
>>> 25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=IZ3U2LUL6yhDK-Uf8F_
>>> eU9W85o61MM43boq-nVwHt38&m=Y1h3ERzFuyyrZqMVfSZPPnKHjrPius4xa
>>> R6YFeyZo70&s=mLeh8MfbUIA3a_yzaiuqc8Cnrf69TAPIK7iocZaNqVk&e=
>>> >
>>>
>>>
>


-- 
Amber Lauer
Postdoctoral Researcher
Triangle University Nuclear Lab
Duke University
amber.lauer at tunl.duke.edu <amber.lauer at duke.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180331/9fc1eb40/attachment.html>