An Apple Pie From Scratch, Part VI Supplement: Climate: Modeling Climate with ExoPlaSim
Modeling climate is, as you may have noticed, difficult. Tools like Clima-Sim can help us along the way, and I’ve done my best to build (through several iterations) a decent process for building climates, but I’ll be the first to admit that it’s still fairly ambiguous in some respects—especially aspects of wind and precipitation that come down to subtleties in convection and turbulence. And of course it becomes even more difficult in exotic cases like tidal-locked or high-obliquity planets, where conventional tools and assumptions break down. It’s easy to understand the desire, widely expressed in worldbuilding circles, to just be able to stick a planet’s geography in a computer simulation that will do the work for us.
Well, today we’re in luck, because I’ve found such a program that can—with certain caveats and restrictions—take any arbitrary geography and planetary conditions and simulate the resulting climate. It’s not quite as simple as just dropping a map in and pressing play, but for a program of its type it’s fairly accessible and I’m hoping that this tutorial can guide anyone through the process of setting it up and running it without requiring any prior experience in coding or running scientific models.
- The ExoPlaSim Model
- Installation
- Installing Linux on a Partition
- Installing Linux on a Virtual Machine
- Installing ExoPlaSim and Dependencies
- Installing on Ubuntu via WSL2
- Configuring ExoPlaSim
- Interpreting the Output
- Dialing in the Climate
- Advanced Use of ExoPlaSim
- Other Climate Models
- Script Templates
The ExoPlaSim Model
PlaSim, short for PlanetSimulator, is a GCM (Global Climate Model or General Circulation Model, depending on whom you ask) designed to serve as an intermediate between simple climate models which don’t fully model a planet’s atmosphere or surface, and highly complex models which require supercomputers to run. Though developed mostly to aid in research of Earth’s current and future climate, it’s also been used to model the climates of exoplanets and Earth’s distant past.
ExoPlaSim is a recent fork of PlaSim, built specifically for use with exoplanets, with two major improvements: For one, it removes much of PlaSim’s bias towards Earthlike climates, and in particular improves its ability to model tidal-locked worlds, though it should be able to model essentially any planet with a broadly Earthlike atmosphere and temperature range; And for another, it couples the model to a Python API, meaning it can easily be controlled by scripts written in Python code (don’t worry; I’ll guide you through the process of setting up such scripts, with no requirement to learn Python coding). It’s intended to allow exoplanet researchers to rapidly run many models of planets with different parameters—such as for example, atmospheric pressure—but it also suits our purposes pretty well, because each model runs fairly quickly even on low-end processors.
In short, ExoPlaSim is not the most detailed or precise
climate model available, but whereas most models in research today would likely
take months at least to run a single simulation on a typical laptop or desktop
computer, ExoPlaSim can do so in hours (it also helps that the primary author, Adiv Paradise—yes, that's his real name—has been incredibly helpful in teaching me proper use of the model and making some adjustments to make it more flexible and intuitive).
There are a couple limitations of ExoPlaSim to be aware of, though:
- First, it’s designed to run at fairly low
resolution. By default it represents a planet’s surface down to a 32 by 64 grid
of cells, each with a single value for elevation, temperature and so on; so
obviously it won’t capture small variations in local climate. It can be run on
resolutions up to 256 by 512, but at that point simulation runtimes may creep
back up towards the months range.
- The current version of ExoPlaSim doesn’t model
ocean currents. Instead it uses a mixed-layer slab ocean: Each cell of
ocean surface is modeled as only 50 meters deep (about the depth of the mixed
layer in the real ocean, the region that directly interacts with the atmosphere
and shifts temperature with the seasons, as opposed to the more sedate deep
ocean), and the ocean can exchange heat with the atmosphere and adjacent ocean
cells, but deep-ocean currents aren't modeled. Some success
has been had coupling PlaSim to a more complex ocean model in the past, and, in
personal correspondence, the author of ExoPlaSim has expressed some interest in
doing the same in the future, but for the moment just bear in mind that, much
as with Clima-Sim, ExoPlaSim may model some high-latitude areas as a tad too
cold for the lack of influencing currents (though the issue appears to be less severe for ExoPlaSim than Clima-Sim).
- ExoPlaSim similarly doesn’t model glacial flow:
Accumulation of snow will form glaciers in the model (if the glaciers module is
turned on), but those glaciers won’t then spread out into surrounding areas,
which is important to the formation of large ice sheets in reality. It may thus
take some extra encouragement to form large ice caps or ice belts.
- For the moment, ExoPlaSim is only set up to
model an Earth-like case of a planet orbiting a single star. It can handle
tidal-locked planets, but in a somewhat artificial way such that it doesn’t
properly handle libration due to orbital eccentricity for them (though it
should work for obliquity). In the future, the model may be coupled to REBOUND,
an orbital integrator, which should allow for any realistic orbital situation
you desire (moons, multiple light sources, various spin-orbit resonances, etc.)
and should even allow for modeling of Milankovitch-like cycles.
- ExoPlaSim uses a simplified model for
representing light, which mostly works fine and has been specifically tuned to
accommodate a broader range of stars, but compared to other models it somewhat
underestimates greenhouse heating from high levels of CO2 (above
~0.1 bar) and may also cause minor inaccuracies for planets orbiting cooler
stars or with thick atmospheres. See a more detailed discussion in section 5 here.
- ExoPlaSim is only really designed to model atmospheres with broadly Earth-like compositions, dominated by N2, O2, CO2, or noble gasses like Ar should all work fine (though it may struggle with very low or high atmospheric pressures). CO2 is the only greenhouse gas modelled (heating by water as a secondary effect of CO2 is modelled, and some heating by ozone can be included but not in a way that would be realistic for planets other than Earth).
By way of comparison, here's a Koppen climate map for a model of Earth run with 300 ppm CO2, resulting in an average surface temperature of 16.5 °C:
There are a variety of minor differences caused largely by the limited resolutions and variations in ground cover not modeled in ExoPlaSim, but a few major differences stand out:
- Northern Europe is somewhat cooler in the model due to the lack of deep ocean currents.
- Antarctica is partially ice-free and Greenland lacks a major glacier, due to the weaker glacial growth; though they may have got a bit larger had I let this model run longer or started with a colder model and then gradually increased temperatures.
- The East Asian monsoon appears to be significantly weaker in the model than reality, making northern China and India drier than they should be in summer and East Africa wetter than it should be. I'm not sure but I think this is somehow caused by the low resolution.
- ExoPlaSim seems to have a bias towards Mediterranean climate patterns (As, Cs, and Ds zones). I'm not really sure why, but averaging the outputs of multiple years together reduces it somewhat.
- Small islands and peninsulas often turn out drier than they should be, which I think is probably a resolution issue again.
All that out of the way, let’s get started.
Installation
Firstly, ExoPlaSim is designed to run on a Unix operating system. Per the readme, it should work fine on recent versions of Ubuntu and CentOS (and OpenSUSE, which I’m using). It should also work on Mac OS X, though with a bit of extra work.
For Windows users, there are two approaches to setting up an environment that ExoPlaSim can run on:
- Install a Linux OS of the sort ExoPlaSim was designed for on a partition on your hard drive, such that you can boot to your usual OS or Linux as necessary.
- Install Linux on a virtual machine within your OS.
The first option is probably the best all-round, and it’s the one I’ll be primarily describing today, though I’ll also relay some instructions from some other ExoPlaSim users who’ve gone with the second option.
Since first writing up this tutorial I've also found that installing ExoPlaSim on Ubuntu via WSL2 on Windows seems to be pretty straightforward and easy, so I've written up a quick section on that as well; this is probably now the best approach for most people, but I've appended it at the end just for organizational purposes; some day I may have time to more completely rewrite this post.
Installing Linux on a Partition
For this option, you’ll need some extra space on your hard drive you don’t mind setting aside (don’t worry, you can uninstall Linux and reclaim that space later if you need to)—ideally at least 40 Gigabytes, but around 10 GB as an absolute minimum—and an empty USB stick or DVD you can dedicate to the purpose (again, you should be able to reformat it and reclaim it for other uses later).
There are all sorts of different options for Linux operating systems, but per the recommendation of the PlaSim authors I’ve been using OpenSUSE (specifically OpenSUSE Leap 15.3, but any recent or future version should work fine), and I’ll describe it’s use here.
OpenSUSE Leap is available for free on its website in two versions: A larger package which contains all necessary files, and a smaller package which requires connection to the internet during installation, which can be a tad tricky to setup but may be faster otherwise on slow connections (because it doesn’t necessarily require downloading all the software packages). In either case the download will contain a CD image file, and the OpenSUSE website has some instructions on loading this data onto a USB stick or DVD such that they can be used for installing Linux.
Past this point, you won’t have access to an internet browser on your computer until OpenSUSE is fully installed, so you may want to read ahead through the rest of this section and take notes if necessary, or open this page on your phone.
The next step is to insert the USB or DVD, then restart your computer and open the boot manager, which can be done in a few ways, often by pressing the f2, f10, or f11 keys during startup, though this will depend on the model of your computer.
This should open the advanced boot options menu, and
you should be able to navigate to a boot manager, where you can both ensure
that booting from USB or DVD is enabled and rearrange the boot order such that
your computer attempts to boot from your USB stick or DVD before booting up
windows from the hard drive. Save these settings and exit, and if everything’s
gone right you should eventually come to a menu looking something like this:
For the rest of the installation, you can refer to the detailed guide here. The short version is that you should generally stick with the default options, but there are a couple steps worth highlighting:
- If you’re using the smaller installation package
which requires an internet connection, setting up the connection can be, as
mentioned, a tad tricky. You should be able to use the same network name and
password as usual, but you may have to play around with different settings for
connection and security type to find one that works.
- The “System Role” step determines what
your desktop and basic interface will look like. “Desktop with KDE Plasma”
is the most similar to Windows, with a taskbar and start menu and so on, and
I’ll be assuming its use for the rest of this tutorial.
- Pay special attention to the next step, “Suggested
Partitioning”. This determines how your hard drive will be partitioned, and
where OpenSUSE will be installed. For a typical computer with a single hard
drive that hasn’t been partitioned before, the suggested setup should be fine;
but otherwise, you may want to go through the “Guided Setup” to ensure
that the partition is going on the right drive, and no existing operating
systems are being removed. You can also alter the size of the partition, though
I don’t recommend going much lower than the default 37 GB, as the default
software packages add up to around 7 GB, ExoPlaSim will need a bit of space to
write files to, and you can always change the partition size later.
- In the “Installation Settings” step, I
suggest keeping the default package. In addition to everything necessary to run
a good desktop environment—and ExoPlaSim, when we get there—it includes Mozilla
Firefox, an internet browser, LibreOffice, a set of programs analogous to
Microsoft Office (LibreOffice Calc seems to run my worldbuilding spreadsheet
just fine) and various other tools for viewing and editing common files. If you
like, you can sort through the software list and remove more frivolous programs
like the games, but those really don’t add up to much drive space.
- During my installation, I was prompted on installing an experimental graphics driver, and, as per the recommendation, decided against it; so I suppose you can do the same if you get the same prompt.
Once the setup is complete, the installation should take no more than an hour or two. You can restart your computer again, and then from the boot menu choose “Boot from Hard Disk” and select your OpenSUSE partition (in the future, you can rearrange the boot order from your boot manager to allow you to boot into OpenSUSE without the USB or DVD).
Installing Linux on a Virtual Machine
Running Linux on a virtual machine may be a little more straightforward for some people and doesn’t require partitioning your hard drive, though it does require using a command line rather than desktop interface and ExoPlaSim will probably run at least a little bit slower this way.
Friend of the blog Alex (Ostimeus on discord) has been running ExoPlaSim this way using Windows Subsystem for Linux and has provided these instructions, which I’ll also relay here:
First, go to Control Panel → Programs → Turn Windows features on and off. Enable “Virtual Machine Platform” and “Windows Subsystem for Linux”. (if those aren’t available check the installation instructions here).
Restart your computer.
Open the Microsoft Store and use it to install OpenSUSE Leap 15.3. If this doesn’t work the first time, restart, go into the BIOS (the same way I describe accessing the boot manager above) and make sure “virtualization” is enabled. If you can’t get WSL2 working, WSL1 should be fine.
Once OpenSUSE is installed, YaST should open. Use the arrow keys or “Tab” to navigate (all the buttons should also have a highlighted letter, and you can select them by pressing “alt” and that letter”).
Installing ExoPlaSim and Dependencies
Once OpenSUSE is installed and open, and you’ve connected it to the internet (at which point you can open Firefox and return to this tutorial, if you like), you can start getting it set up to run ExoPlaSim. OpenSUSE comes with Python3 installed by default (If you’re using a different operating system, you may need to install it) but we also need some additional packages (essentially, files containing additional functions that python can use) to run ExoPlaSim. But this is pretty straightforward in OpenSUSE:
In the Start menu at the lower left (in the KDE Plasma desktop) go to Applications -> System and open “YaST Software”. For each of the below software packages, type in the name in the search box on the left, find the package in the list that matches that name, press the box to the left of that package such that it shows a “+” sign (if it doesn’t have a check in it already), press “Accept” in the bottom right. YaST will automatically find any dependencies, which you should accept as well, and then install them.
(VM users can open YaST by typing in sudo yast, and then navigate the program using the “Tab” key to cycle between buttons and selection boxes and “Enter” to select them.)
The required packages are:
netcdf
python3-devel
gcc-fortran
gcc-c++
make
openmpi
openmpi-devel
netcdf-devel
(VM users will also need python3-pip)
These next packages used to be necessary for older versions of ExoPlaSim and shouldn’t be required for the current version, but just in case I’ll leave them here for reference:
python3-cairo
libnetcdf_c++-devel
xorg-x11-devel
(I also used to advise getting numpy, scipy, and matplotlib though YaST, but for whatever reason some key files are left missing in the numpy install; fortunately the “pip install exoplasim” step in a little bit will install these on its own, and do so properly, so just let that handle it; to be clear, do not install numpy on its own)
For most of these packages, installing them through YaST is all the setup you need. But the openmpi-devel package (which is necessary for running the model with multiple processors) requires one extra step:
In the Start menu, go to Applications -> System and open “File Manager – Super User Mode”. This allows us to alter files and folders that are usually protected, so you shouldn’t get used to using it, but we’ll need it just this once.
On the bar on the left of the window, you should see a list of “Devices” on the bottom, which will include your partition; it’s labeled as “35.0 GiB Hard Drive” on my installation (you can also access the files in your Windows partition in that list, though this doesn’t always seem to work, likely because Windows includes a “fast boot” function that means it doesn’t completely stop running even when shut down). Within that device, navigate to:
usr / lib64 / mpi / gcc / openmpi / bin
Copy the contents of that folder, and paste them to:
usr / bin
And close the file manager, as we won’t need it anymore; we can use the regular “Dolphin” file manager from here on out. This may not be the most elegant method of getting ExoPlaSim to use these files, but it seems to have worked fine for me.
(VM users should:
- enter cd .. and then ls until it shows a list of files that includes “usr”
- enter sudo cp -r usr/lib64/mpi/gcc/openmpi/bin/* usr/bin/
- if
that doesn’t work, you can also try:
sudo cp -r usr/lib64/mpi/gcc/openmpi/bin usr/bin/bin
sudo mv usr/bin/bin/* usr/bin/
sudo rmdir usr/bin/bin - If this has worked, the number of files within usr/bin should have increased by 68
- make sure to return to the default path using cd)
That done, open “Konsole” (VM users will already by using it); it should be in the favorites tab in the start menu, otherwise look in Applications -> System. This is a command-line interface, and though It may look a little daunting, there are only a few commands we need to input here. One thing to note is that the usual “Ctrl-c” and “Ctrl-v” shortcuts for copy and paste won’t work in Konsole, but right-clicking will still work.
First off, to install ExoPlaSim, type in:
pip install exoplasim[netCDF4] --user
(temporary note; a fair few people have had issues getting version 3.3.0 to work properly, so if that's still the latest release you might want to instead install the previous version with pip install exoplasim[netCDF4]==3.2.4 --user)
It should download and install ExoPlaSim and a couple dependencies (numpy, scipy, and matplotlib, which are also required for some of the scripts I’ll mention later). It may do so haltingly; just wait until it completes and you have a line ending with your username ending in “:~>” before you attempt to type anything more in. It may throw an error about some scripts being outside your “PATH”. To solve this, type in:
PATH=$PATH:/home/user/.local/bin
Where “user” is your username, as shown in the error:
And be sure to run at least one ExoPlaSim script before you
next close Konsole; the scripts referred to in the error are only needed for
first configuration, but Konsole doesn’t seem to remember the PATH command
between sessions. You’ll also need to put this command in again if you ever
update ExoPlaSim or alter its files such that it needs to configure again;
Alternatively, a more permanent solution would be to open the ".profile" file in
your home folder (if you can’t find it, select the icon in the top right of
Dolphin and select “Show Hidden Files”), paste in the command and save it. From then on, the command should be run every time you boot up OpenSUSE.
If you ever encounter an error referring to “No module named exoplasim.pyfft’, this indicates that ExoPlaSim was configured without a proper path. The simplest fix is to navigate to home / .local / lib / python3.6 / site-packages (again, show hidden files if you can’t find “.local”), delete “exoplasim”, and then reinstall and reconfigure it.
If that doesn't work, an alternative is to compile the exoplasim.pyfft file manually by navigating to the exoplasim directory (which may be slightly different depending on your install details):
cd /home/user/.local/lib/python3.6/site-packages/exoplasim
Where "user" is your user name, and then running:
python$pyversion -m numpy.f2py -c -m pyfft --f90exec=gfortran --f77exec=gfortran --f90flags="-O3" pyfft.f90 && mv pyfft.cpython*.so pyfft.soIf you want to use the T63 resolution (96x192 cells), you'll also need this command (though I haven't tested yet if this actually works):
python$pyversion -m numpy.f2py -c -m pyfft991 --f90exec=gfortran --f77exec=gfortran --f90flags="-O3" pyfft991.f90 && mv pyfft991.cpython*.so pyfft991.so Entering cd again should bring you back to your home folder
If all goes well then it’s time to make our first python script to run exoplasim. To open a new script, type in:
kate program.py &
The “program” bit here can be any name, so long as it has the “.py” file type (the “&” bit is also optional, but without it we’d have to close the script to use Konsole again). This should open a new window showing an empty text file (you can also make and edit scripts in the “Home” directory as you would with any text files, I just figured we’d use Konsole while it’s open; and giving the file the “.py” ending from the outset causes the text editor to helpfully color code script elements in a manner appropriate to python, in a similar manner to the embedded script below). You can copy and paste text in here as normal.
(Kate doesn't seem to be installed with the VM version, so VM users should create their scripts in windows using something like notepad++. You can then open file explorer and type in \\wsl$ in the directory bar, giving you access to the WSL files such that you can drag files in and out.)
First off, let’s run a short script just to check that ExoPlaSim has installed right. Copy this text into your script:
I’ll explain what all this means later, for now the only section you might need to change is the “ncpus” parameter, which indicates the number of processor cores the model will work on. To check how many cores you have, in the Start menu go to Applications -> System and open “Info Center”, which should show your processors under “Hardware”. For example, on my system it shows “Processors: 8
x Intel® CoreTM i7-7700HQ CPU @ 2.80GHz”, indicating that I have 8 cpu cores, so I’d want to put “8” instead of “4” for the ncpus parameter in my script.
(VM users, if you can find the "Device Manager" in the control panel on Windows, it should include a list of your processors)
Save the script, then return to Konsole, and type in:
python3 program.py
(Or whatever else you called the script, if not “program”.)
The first time you run a model with ExoPlaSim, it will go through a configuration process that shouldn’t take too long. It will spit out a lot of text into Konsole, some of which may be warnings and errors, but so long as there isn’t any red text, you can ignore it all (if there is red text, it probably means you missed one of the software packages). Once that’s done, it will compile the specific model specified in the script and run it. That should look something like this:
You can safely ignore all those “an array temporary was created” warnings, and you’ll know a model year has passed whenever a new batch of them appear. So long as you don’t see something about exoplasim producing junk data and needing to stop, the model should be running fine. To double-check, you can open the “Home” directory (there should be an icon on the desktop, and starting the “Dolphin” file manager will open to it by default) and find a folder called “mymodel_testrun”, within which you should find some files that are being continuously rewritten. There will also be a “snapshots” folder, in which you should find a new file appearing once every simulation year.
(VM users may run into “Permission denied” errors. This may just mean that you need to delete the working directory, e.g. “mymodel_testrun” before running the file again, but if that doesn’t help you may also need to:
- enter cd .. and then ls until it shows you a list of files including “home”
- enter sudo chmod -R a+w+x *home*
- reinstall ExoPlaSim)
Anyway, this test script runs a climate model with all the default settings, at about the minimum reasonable resolution and precision, for 10 years. Depending on your processors, this can take anywhere from under 10 minutes to over an hour—which should give you a rough benchmark of about how quickly your computer will run ExoPlaSim in general. You can do other things like browse the internet while it’s running, though I’m not sure how much that might affect the runtime.
Once it’s complete, ExoPlaSim should show a message in Konsole, delete the “mymodel_testrun” folder, and create a “mymodel_ouput” folder containing the state of the model in the final year of the simulation. If something went wrong it will create a “mymodel_Crashed” folder instead.
Installing on Ubuntu via WSL2
sudo apt install -y f2c
sudo apt install -y fftw3
sudo apt install -y openmpi-bin libopenmpi-dev
sudo apt install -y python3-pip
sudo apt install -y python-is-python3
pip install exoplasim[netCDF4]==3.2.4
python$pyversion -m numpy.f2py -c -m pyfft --f90exec=gfortran --f77exec=gfortran --f90flags="-O3" pyfft.f90 && mv pyfft.cpython*.so pyfft.sopython$pyversion -m numpy.f2py -c -m pyfft991 --f90exec=gfortran --f77exec=gfortran --f90flags="-O3" pyfft991.f90 && mv pyfft991.cpython*.so pyfft991.so Configuring ExoPlaSim
Presuming that everything went well and the model seems to be functioning normally, we can now start creating our own scripts for modeling our own planets. ExoPlaSim has fairly extensive documentation of its own, including some tutorials on running models and interpreting their output, but for the sake of convenience I’ll describe all the parts of the scripting language I think you might need to use for broadly Earthlike planets.
Alex has now made a configuration tool for creating a script (and uploading terrain) via a simple interface, without writing it all up yourself. I still recommend reading through this section to understand what all the options are, and it may be especially helpful if you want to adjust the script or do something more advanced than run a model through once.
To start out with, here’s what a typical ExoPlaSim script might look like (in this case, it’s the setup I’m using for my example world, Teacup Ae; given how many values I tweaked, I strongly recommend using one of the template scripts at the end of this post rather than this one as a basis for your own scripts):
(Note that I’ve added a couple extra lines and spaces here for clarity: in Python scripts, you can add empty lines (though not extra indents), extra spaces before and after operands (=,+,-,*, etc.) and after commas, and use single quotes (‘) or double quotes(“) interchangeably (though any one string must start and end with the same characters, e.g. you can use ‘teacup’ or “teacup” but not ‘teacup”), all without changing the behavior of the script.)
To understand what’s going on and what we can change, lets go through this script line-by-line.
import exoplasim as exo
This just tells python to find ExoPlaSim’s library of special functions, and gives it the shorthand “exo” to refer to them later. You should always include this line at the start of any script for ExoPlaSim.
This sets up the model for my planet, and gives it the shorthand “teacup” for referring to it later. Within the parentheses are various parameters for the model. These parameters can be entered in any order so long as they’re all separated by commas (e.g. I could have written crashtolerant=True at the start or in the middle instead, without changing the meaning) and they’re all optional; any parameters you don’t enter will default to values appropriate for a simulation of Earth. Let’s go through the parameters one by one, including a couple I don’t normally use but may be useful to you in the future:
workdir
Sets the path and name of the folder in which the model holds its files while running. As just a name it will put the folder in the home directory, but if you add a path you can place it elsewhere. In either case, paths and names should always be enclosed in single (‘) or double (“) quotes (again, either is fine, but don’t mix them for one name).
modelname
Sets the name used for the output folder and some output files.
outputtype
Controls the filetype of the output files. ‘.nc’ will produce netCDF files, which can be read by a couple of the tools I describe later. Various other types are available, though a few may require additional software packages.
resolution
This sets the resolution used for modelling the planet’s surface, and thus the resolution of the geography we can import into the model and the output we’ll get. These are the resolutions ExoPlaSim can handle, and the associated codes to input here:
|
Code |
T21 |
T42 |
T63 |
T85 |
T106 |
T127 |
T170 |
|
Height |
32 |
64 |
96 |
128 |
160 |
192 |
256 |
|
Width |
64 |
128 |
192 |
256 |
320 |
384 |
512 |
T21 is the default resolution, and you should generally use it for most purposes of testing and playing around, but many details of climate are lost at such low resolution, so it’s best to use at least T42 for outputting actual maps of the planet. Bear in mind that the highest resolution, T170, contains 64 times as many cells as T21, which implies an order of magnitude or two longer runtimes—likely more, as higher resolutions seem to be less stable and so require higher precision modelling in other respects. So far I've only tested T21 and T42 resolutions myself, but I know others who have performed brief T63 runs (~10 model years) on their home computers.
With recent exoplasim versions T63, T106, and T127 may not run properly; see notes in the above installation instructions about manually compiling the appropriate exoplasim.pyfft file.
layers
Sets the number of atmospheric layers modeled—in essence, the vertical resolution of the model grid. This is 10 by default, but low-resolution models seem to work fine with 5, which also saves a good deal of computing time. Higher-resolution models may require more layers for best accuracy, but that would even further extend the runtime.
ncpus
As already described, the number of processors to run on, which you should generally set to the total you have available (you can still do other things on the laptop like browsing the internet while the model is using all cores, though it may be a bit slow). The number of latitude cells has to be a multiple of ncpus; so if you're using T42 resolution, with 64 latitude cells, you could use say, 4, 8, or 16 cpus, but not 6.
precision
The precision (in bytes) of some internal numbers used, either 4 or 8. 4 will run a tad faster, but may be a little less stable and more prone to crashing, so 8 is the default.
crashtolerant
If set to True, then if the model crashes (and at least 10
years have been simulated), it will rewind 10 years and try again. This can
help get around some crashes caused by essentially just random noise in the
model, without requiring you to manually restart it each time. On the other
hand, if there’s some more fundamental issue with the model (e.g., it’s warming
to the point that the oceans start boiling away) then this feature could cause
it to be trapped in an infinite loop; so it’s probably best to leave it off if
you’re “exploring” new configurations, and to check up on the model when you do
turn it on. Note that for this and other True/False configurations, True and
False have to be capitalized, and shouldn’t be placed in quotation marks (Kate should helpfully highlight them a different color if you format them right).
inityear
The number to use for the first year of output, with
subsequent years counting up from there. May be useful if you’re continuing an
old model and want to keep all the years from the full model in order. Do note, though, that the runtobalance command we'll use later requires that you have the outputs from all years from 0 to the current one in your work directory.
recompile
If set to True, forces exoplasim to compile again before running. May be useful if you’ve altered some of the source files (though I won’t discuss anything like that here).
Moving on…
A couple syntax notes:
- I’ve used the shorthand, teacup, I established in the last line to refer to the model here.
- I’ve broken the parameters inside the function over several lines for clarity; you can break up the parameters any way you want like this, so long as every line after the first is indented by the same amount.
- Any parameter that requires numerical input can also take a mathematical expression. You can use +, -, *, and / as you'd expect, use ** for exponentiation (e.g. 2**3 is 23), e for scientific notation (e.g. 350e-6 is 350*10-6), and parentheses for controlling the order of operations.
This line further configures the model (in ways that don’t require it to be recompiled, hence the 2-step configuration). Once again, let’s go through the parameters, this time breaking them down into some broad categories:
Model Setup
timestep
How much time passes in each step of the simulation, in minutes. Longer timesteps will make the simulation run faster, but it may be less stable and accurate. This is 45 by default, but for tidal-locked planets it’s recommended that you reduce it to 30, and in general if you hit a crash—especially if the Konsole output refers to “non-finite temperatures”—your first instinct should be to reduce the timestep. I’ll say a lot more about working with the model’s timekeeping in a bit, for now I’ll just say that it generally seems to work better if there are a whole number of timesteps in a 24-hour day.
snapshots
If set, the program will produce a “snapshot” whenever this number of timesteps passes, recording the state of the model at that particular moment. If using this, it’s recommended to set it to be equal to around 15 days such that it doesn’t slow down the model too much (so, 480 for a 45-minute timestep. 720 for a 30-minute timestep, and so on).
runsteps
The number of timesteps in a simulation year (must be a whole number). By default this is set for a 360-day year, e.g. with a 45-minute timestep it is 11520 (it will automatically adjust to different timesteps if not configured here). This does not alter the simulated planet’s orbital period, or really any aspect of its climate; it merely alters the period of time referred to in later steps that run the model for a period of years, and the length of time represented in the output files. Again, I’ll explain some considerations for the model’s timekeeping a bit later.
physicsfilter
Adds a couple filters to the numbers running through the model, which can help prevent crashes and odd outputs (and in particular removes some artifacts known to arise for tidal-locked planets). For a fairly earthlike planet at T21 resolution, this isn’t necessary, but for tidal-locked planets, planets with very sharp topography, higher resolutions, or any other models that are consistently crashing, it’s recommended you set physicsfilter=‘gp|exp|sp’
restartfile
Path to a restart file. As a model runs, it produces a restart file each year, which holds the current state of the model at the end of that year. If you want to continue running a model after its run (or if you want to try continuing a model that crashed) then you can use this parameter to point the model to that restart file, and it will pick up modelling from that saved climate state. You can even continue running with some of these configure parameters changed (e.g., you can alter CO2 levels to warm or cool the planet). Note that if you do restart, you shouldn’t change the resolution, layers, or precision in the exo.model step, but you can probably change everything else (I haven’t tested this thoroughly).
otherargs
Alters an additional internal parameter not usually available through the configure function, in this case NSTPW (I think it’s short for “Number of STeps Per Write”, but I’m not sure) which controls how often data recorded from the model is averaged together. I’ll explain the significance of this later, but for now just know that to change this you only need to alter the number at the end (the 160 in {'NSTPW@plasim_namelist':'160'}).
Star and Orbit
flux
The flux of sunlight hitting the top of the planet’s atmosphere, in watts/meter2. By default this is 1367, the value for Earth. Teacup Ae receives 74% as much light as Earth does, hence 0.74*1367. You can determine how much light your planet receives, relative to Earth, with my worldbuilding spreadsheet, or just with the formula [flux] = 1367 * [star luminosity compared to sun] / [distance from star in AU]2.
startemp
The effective temperature of the star, in Kelvin, which will
be used to adjust atmospheric absorption and surface albedo. It does not affect flux or or year length; the onus is on you to find a set of values corresponding to a realistic scenario (if you want to). If not set, a
sunlike star will be assumed.
year
Length of the year, in 24-hour Earth days. Defaults to
365.25, the value for Earth. This controls the period the planet takes to orbit
its star, not the length of the years used for the output files and the model run controls—those are set by the runsteps parameter, though generally
speaking you should probably make them the same, except for very short orbital
periods. Again, you can use my worldbuilding spreadsheet
to help determine this and other values—or you can use [orbital period in
years] = sqrt( [semimajor axis in AU]3 / [mass of star compared to
sun].
eccenticity
Eccentricity of the planet’s orbit. Defaults to 0.016715, the value for Earth.
fixedobit
True forces the orbit to remain unchanged throughout the simulation, False allows for ExoPlaSim to calculate Milankovitch cycles to alter the planet’s orbit and orientation. The latter feature is still under development, so it’s probably best to keep this on for now.
Rotation
rotationperiod
Rotation period of the planet, compared to Earth. This is a sidereal day (23 hours 56 minutes for Earth), but for planets with many orbits per year it should be an insignificant difference from a solar day, so don’t worry too much about the difference. Defaults to 1.
obliquity
Obliquity, A.K.A. axial tilt, in degrees. Defaults to 23.441, the value for Earth.
lonvernaleq
Longitude (angle along the orbit) of periapsis (point when the planet is closest to the star) in degrees, measured from the autumnal equinox, which is used to orient the planet’s rotational axis relative to its orbit. Defaults to 102.7, the value for Earth. This should be 90 degrees less than the argument of obliquity (adding 360 if the result is below 0), so:
0: periapsis coincides with the autumn equinox in the northern hemisphere
90: periapsis coincides with the northern winter solstice
180: periapsis coincides with the northern spring equinox
270: periapsis coincides with the northern summer solstice
(Okay, formally “longitude” is a compound angle measured along two planes, but if we consider the orbit to have 0 inclination, then those become the same plane and match the orbital plane. Also, most sources will say that longitude of periapsis is measured from the vernal equinox, but what they mean is that it’s the point on the object’s orbit that’s directly overhead during midday on the vernal equinox, and if you’re measuring this for the body you’re standing on, it’s actually the point on the opposite side of the orbit; hence, the autumnal equinox.)
Tidal-Locked Planets
A couple of parameters specifically for use with planets tidally locked into a 1:1 spin-orbit resonance. Because of small errors in the model’s internal timekeeping, we can’t simply match the rotation period and year length; the errors will cause the substellar point to drift over time. Instead, tidal-locking is modelled by locking the substellar point to a given latitude. This means that the substellar point can oscillate north and south for planets with nonzero obliquity, but currently it won’t oscillate east and west as it should for planets with eccentricity. This should be fixed in the future when proper orbital simulation is added to ExoPlaSim, which will also allow for easier simulation of other spin-orbit resonances.
synchronous
True locks the sun to one longitude.
substellarlon
Longitude of the substellar point, in degrees. Defaults to 180; though if you import geography by the method described later, starting with a map with 0 longitude at the center, then the geography of your map will be offset 180 degrees from the model’s coordinate system, so the default of 180 would actually place the substellar point at 0 longitude (you may want to run a quick test when setting up a model like this to ensure everything’s in the right place).
desync
Rate at which the substellar point drifts from its initial longitude, in degrees per minute (I presume to the east). You could use this to approximate spin-orbit resonances other than 1:1 (i.e. drift of 180 degrees per orbit would approximate the 3:2 resonance), but again the effects of eccentricity on the movement of the substellar point are not properly modelled in the current version of ExoPlaSim. Defaults to 0, can be positive or negative.
tlcontrast
Adds an initial temperature contrast between the substellar point and the antistellar point, in Kelvin. Defaults to 0. Increasing it to, say, 100 might help the model balance faster.
A while back I also made some edited versions of the exoplasim files which should properly account for eccentricity for tidal-locked planets, which you can find here (it's on my patreon but should be publicly visible without needing to join). It should also allow other spin-orbit resonances, but I have seen at least one person get some odd behavior testing a 2:3 resonance, so I may have to check through that function again (not sure when, I'm not eager to dig into fortran code again).
Planet
gravity
Acceleration due to gravity at the planet’s surface, in meters/second2. Defaults to 9.80665, the value for Earth.
radius
Radius of the planet relative to Earth.
landmap
Path to a .sra file containing a land/sea mask for the planet’s geography. We’ll discuss how to make these files later. If you don’t define a landmap or topomap, it’ll default to Earth’s geography (at least for T21 and T42 runs).
topomap
Path to a .sra file containing the planet’s topography. Again, we’ll discuss how to make them later.
orography
Scaling factor applied to the above-defined topography, down to flat continents at 0.0. Extreme conditions on high mountain peaks or deep valley floors can sometimes cause crashes, so flattening out the topography can help you tell if that’s the issue.
aquaplanet
True erases all land surfaces (including the default earth geography) and gives you a uniform, all-ocean planet. This may run a bit faster, so it can be useful for debugging or quick tests of other factors.
desertplanet
True erases all seas and gives a fully land-covered planet.
Atmosphere
Can be set in two ways:
- Set the partial pressures of all the gasses in the atmosphere, out of the list of preset gasses, and allow ExoPlaSim to calculate total surface pressure and the effective gas constant.
- Set the total surface pressure and gas constant directly, and optionally set the partial pressure of some of these gasses out of that total.
Be aware that the model can struggle a bit with surface pressures greater than 10 bar or less than 0.1 bar; it can be done, but you may need to significantly reduce the timestep, to as little as 5 minutes. Also bear in mind that some of the model’s internal workings assume an atmosphere with broadly Earthlike composition (nitrogen/oxygen dominated), and so may not be fully accurate for other atmospheres.
pH2
Partial pressure of hydrogen (H2) in bars. As of version 3.3.0, ExoPlaSim isn't a great model for atmospheres of mostly hydrogen or helium with water oceans because it doesn't model the ways in which convection and other processes change when average atmospheric density is less than that of water vapor.
pHe
Partial pressure of helium (He) in bars.
pN2
Partial pressure of nitrogen (N2) in bars. Earth has 0.7809.
pO2
Partial pressure of oxygen (O2) in bars. Earth as 0.2095.
ozone
True adds an ozone layer, which slightly increases greenhouse heating, among other effects. Any planet with oxygen should probably have some ozone as well, but ExoPlaSim’s handling of ozone has been tuned to match Earth and may not be very accurate for significantly different atmospheres or stars. At a guess, I’d say you could maybe still use it for Earthlike planets with significant atmospheric oxygen orbiting sunlike stars, but it may be best to exclude otherwise, even though this may cause a slight underestimate in greenhouse heating (though that’s already the case for planets with high CO2).
pAr
Partial pressure of argon (Ar) in bars. Earth has 0.0093
pNe
Partial pressure of neon (Ne) in bars.
pKr
Partial pressure of Krypton (Kr) in bars
pCO2
Partial pressure of carbon dioxide (CO2) in bars.
Other than ozone, this is the only greenhouse gas you can directly set. Earth
had around 0.00028 prior to the industrial revolution, and at time of writing
is rising past 0.000416, but the model defaults to 0.0003.
pH2O
Partial pressure of water (H2O) in bars. This only affects surface pressure and the gas constant; it is not referenced in determining humidity, any aspect of the water cycle, or greenhouse heating by water vapor.
pressure
Total surface pressure in bars. Unnecessary if you’ve already set all the partial pressures of the component gasses in your atmosphere, though you can combine this with the partial pressures of some of the component gasses (in which case you should set a gas constant as well). Defaults to 1, if no partial pressures have been set.
gascon
Effective gas constant, in Joules / (kilograms * Kelvin). Can be calculated as the molar gas constant (8.314 J / K*mol) divided by the average molar mass of the atmosphere, in kg/mol. Defaults to 287, the value for Earth, if no partial pressures have been set.
Surface
wetsoil
True alters the albedo of land surfaces based on how wet they are; wetter land has a lower albedo, so it reflects less light. This is another parameter tuned to observations of Earth, so it probably should be used with significantly warmer or cooler stars.
soilalbedo
Can be set to a fixed albedo value that will be used for all land. You usually shouldn’t do this for Earthlike planets, but you can use it to model some sort of unusual desert planet covered in more reflective desert sand or salt.
vegetation
Controls a vegetation model, which will impact surface albedo and humidity. It’s not a very advanced model and probably won’t handle particularly exotic climates too well, but it’s still nice to have. 0 or False will leave the model off, 1 or True will activate "diagnostic" vegetation which is fixed to an initial value of vegetation cover across all land, 2 will activate a coupled vegetation model which will grow and die back in response to the local climate, and produce an estimate of the resulting forest cover in the output. This will probably slow down the model to some extent, so you might want to leave it off until you’re putting together a final model.
vegaccel
Accelerates the rate of vegetation growth. 1 by default, must be an integer. I don’t know of a specific case where you’d want to change this, but it’s there if you need it.
initgrowth
Adds vegetation cover to all land at the start of the model, which might save some time running the model to equilibrium and make the resulting climate somewhat less arid than it would be if it started without vegetation. Should be between 0 and 1, 0.5 is probably good for most cases.
glaciers
Controls the formation of glaciers. As it stands, turning this on allows for persistent deep snow in a cell to form glaciers, but these glaciers don’t flow outward into other cells as would be realistic, so this model may underestimate the extent of large continental glaciers. It’s a sort of compound parameter with a different syntax:
glaciers = {‘toggle’: True, ‘mindepth’: 2, ‘initialh’:-1}
Going through each subparameter:
toggle
True allows for new glaciers to form. False by default.
mindepth
Sets the minimum depth of accumulated snow required for glaciers to form, in meters. 2 by default.
initialh
A value of 0 or greater will place glaciers with that depth in meters over all land surfaces when the model starts, and a value of -1 will not add any initial glaciers.
That’s about wraps it up for the configure function, though there are some additional options I’ll discuss later.
teacup.cfgpostprocessor(times = 12)
This configures the postprocessor that converts the model’s
data into readable output files. Here I’m just using the times parameter to
set the number of months per year in the output (it should be 12 by default, so
it is actually redundant here). This can occasionally cause issues, so it's probably best to leave this line out if you don't need it (adding outputtype = '.nc' as another parameter may help)
teacup.exportcfg()
This line saves all that configuration information (from the teacup.configure line, not from exo.model line) into a config, by default named with the set modelname. Then you can run the same model later by just loading that config, e.g. teacup.loadconfig(‘teacup.cfg’)
This is the main command to run the simulation. We used a simpler run command before where we just specified the number of years, e.g. teacup.run(years=100). But this runtobalance command instead runs the model until it appears to have reached equilibrium, as judged by the balance between average incoming sunlight and outgoing heat remaining unchanged over several years. How long this takes can vary quite a bit, so it helps to have this option rather than having to guess a reasonable timeframe. Anyway, here are the parameters:
baseline
How many years the simulation has to remain at equilibrium before it is determined to be at balance (i.e., the amount of drift per year in the balance of incoming and outgoing energy has to remain below the threshold for this many years). Defaults to 50, but for our purposes around 10 Earth years is usually fine.
maxyears
The maximum number of years for the simulation to run, even if it hasn’t reached balance by the end. Defaults to 300.
minyears
The minimum number of years for the simulation to run, even if it has reached balance by the end. Defaults to 75, but again a low number like 10 is usually fine, and can especially save time at higher resolutions.
timelimit
A time limit in minutes for the simulation. If set, the model will dynamically alter the maxyears parameter to attempt to end the simulation before this limit.
crashifbroken
This just helps make crashes a little more graceful and gives you somewhat more useful error reports.
clean
Deletes temporary files produced each year once an output has been created, which should help limit the amount of hard drive space used while running.
teacup.finalize()
Moves the output files to a new folder, named according to the first parameter (‘teacup_out’ here; this must be placed first in this case)
allyears
If set to True, moves the output files from every year of the model run; otherwise, it only moves the final year. These output files can take up a good bit of hard drive space, but if you’re making a final run you intend to use for a Koppen zones, I suggest using this so you can average together the data from multiple years when making the map. False by default.
keeprestarts
If set to True, moves the restart files—which can be used to restart and continue running the model—as well as the outputs. False by default.
clean
If set to True, deletes the model run folder and all files after making the new folder. True by default.
teacup.save()
This saves the model in its current state as a numpy file. By default it will be saved as a .npy file with your model name, but you can also enter a name inside the parentheses (in quotation marks). You can then load it again in another script like so:
Unlike a restart file, this doesn’t require any other setup commands and will remember the year of the model and information from previous years; in essence, it allows you to pick back up from the same point in the script as when you saved it. However, it requires the other files in your model's run folder, including outputs from all years for the runtobalance function, whereas a restart file is self-contained (within your computer, anyway; a restart file moved between computers is unlikely to work properly); so using restart files can help save a lot of hard drive space.
Regarding Timekeeping
Though I’ve mentioned some of the constraints of specific parameters related to how the model keeps time, let’s take a moment to put it all together.
See, the ultimate goal here is to produce a Koppen climate map, but the Koppen scheme wasn’t really built with exoplanets in mind. On earth, Koppen zones are defined by monthly averages of temperature and precipitation (1/12 of the year), as well as total precipitation over summer and winter (1/2 of the year) and whether temperatures over 10 °C last at least 4 months (1/3 of the year). So if we want a Koppen map for a planet with a year, say, half as long as Earth’s, we have to ask: is it better to ensure the year is still divided into as many months as Earth (12 months of ~15 days each) or is it better the ensure that each month is as long as on Earth (6 months of ~30 days each) to ensure that the map is accurately reflecting how different seasonal patterns affect local climate and life? And if the latter, what do we do when the number of ~30 day months in a year can’t so easily be split into halves and thirds?
We also have to consider whether our paradigm of seasons can reasonably be applied to very short-period planets, even those with significant obliquity or eccentricity. If a year is only 10 days long, are trees going to shed their leaves in fall just to regrow them in spring 5 days later? Reasonably, there must be a point where annual climate variations go from “season-like” to “day-like” in terms of their impact on life, but where would it be?
I can’t say I know the right answers to these questions, but ExoPlaSim functions in such a way that it constrains our options somewhat. Here’s a basic summary of how the model handles its timekeeping:
The model runs in steps, and the interval between them is set by the timestep parameter. Each step, it saves some data about the current state of the planet to memory. If you have set the snapshots parameter to some value, then at regular intervals (that number of timesteps) the data from the current step will be saved to a dedicated file (and all snapshots are ultimately saved to one file for the year).
But we’re mostly concerned with the main output. After a certain number of timesteps have passed, determined by the NSTPW parameter, the recorded data will be averaged together, and those averages will be saved to memory. This helps limit the total amount of memory the model has to use at once.
After a larger number of timesteps, set by the runsteps parameter, the model will save its recorded data to file. This is done by taking the averaged data recorded at each NSTPW interval, dividing these up based on the number of desired months—set by the times parameter—and then averaging the data in each month, to get one averaged value for the whole month for each data parameter. The result is output as a netCDF file (if you’ve set that filetype). If we want to produce Koppen climate maps from these output files, then each file should represent a year—one complete orbit of the planet around the sun, which is determined by the year parameter.
Ideally, we want an even number of NSTPW intervals in each month, so that each month in the output is representing an even amount of time in the simulation (the model will attempt to interpolate data if there are uneven numbers of these outputs in each month, but we should still try to avoid that necessity). Thus, if we have 12 months in a year, there should be some multiple of 12 NSTPW intervals in a year (in mathematical terms, we should ensure that NSTPW = runsteps / (times * n), where n is an integer). However, by default NSTPW is calculated from the timestep such that it’s interval is about 5 days (120 hours), and we shouldn’t move it far from this value; a much shorter interval would require the model to average together and write out data more frequently, which will slow it down, whereas a longer interval will increase the amount of memory the model has to use, which can cause it to crash.
We also ideally want an even number of days each month—in terms of solar days, set by the rotationperiod parameter (sort of; strictly it alters the sidereal day, and I'm not totally clear on whether ExoPlaSim uses the year parameter to determine synodic days, but for large year/day ratios it shouldn't matter much), not 24-hour Earth days—or else we might get some odd edge effects (e.g. one month may get more daytime hours and the next more nighttime hours, such that the former has a higher average temperature even if daily average temperature is constant).
Thus, here are the overall meanings and limitations of these values (in the associated expressions, n must be an integer, though not necessarily the same integer in each case):
- timestep: the length of each model step, in minutes. Generally the model seems to work best if there is an even number of timesteps in a 24-hour Earth day; so timesteps of 5, 6, 10, 12, 15, 18, 20, 24, 30, 36, 40, 45, and 60 minutes are all decent options.
- (24 * 60) / timestep = n
- NSTPW: how often data is averaged together, in number of timesteps. The amount of time this represents should be kept close to 120 hours. It need not necessarily be a whole number of solar days, though that may be convenient to help keep things straight.
- ~4 < (NSTPW * timestep) / 1440 < ~6
- runsteps: how often averaged data is written to an output file, in number of timesteps. We’re taking this to be a “model year”, though it doesn’t directly control any aspect of the planet’s simulated orbit. Should contain a whole number of NSTPW intervals.
- runsteps / NSTPW = n
- year: the length of the planet’s orbit, in 24-hour Earth days. To properly produce Koppen maps from the output files, this should be the same length of time as the model year.
- year * 1440 = runsteps * timestep
- times: the number of output times in the output file for each model year, taken here to represent “months”. Per our earlier discussion, for use with the Koppen system, you may want to keep this as 12, or at least some multiple of 6. Each month should contain an even number of NSTPW intervals.
- runsteps / times = NSTPW * n
- times = 6 * n
- rotationperiod: the length of a solar day (roughly), in 24-hour Earth days. Ideally there should be a whole number of timesteps in a solar day, and a whole number of solar days in a month.
- (rotationperiod * 1440) / timestep = n
- runsteps / times = (rotationperiod * 1440 / timestep) * n
This can be a lot to handle, and it’s not strictly necessary that all of these be true; again, the model can interpolate data some if the NSTPW and month times don’t quite line up right. But you should try to tweak you parameters somewhat to accommodate the model’s limitations where you can.
So, let’s consider Teacup Ae’s case: we’ve established previously that the planet has 34-hour days, and 93 of those days in a year. But for purposes of the model we can round that up to 96 days (136 Earth days), so it can be divided into 12 months of 8 days each. Each month will be 272 hours long, 11 1/3 Earth days. We can thus slightly increase the NSTPW interval from 120 to 136 hours (5 2/3 Earth days) for 2 writes a month. 136 hours unfortunately doesn’t divide evenly into 45-minute timesteps, but it should work with 30-minute, 40-minute, and 60-minute timesteps, with corresponding write intervals of 272, 204, and 136 timesteps. And we can adjust runsteps accordingly for a 3,264-hour year, and set the year parameter to 136 Earth days.
As a final note, there is still the aforementioned case where orbits are so short that the planet doesn’t really have “seasons” in the sense we understand them. 24 Earth days is about the minimum year length for which we could reasonably interpret Koppen zones from the model output (4-day NSTPW interval * 6 months), but really I’d be skeptical applying it to anything with a year shorter than a couple months (~60 days). In these cases, it may be best to apply a reduced set of “seasonless” Koppen zones, as I’ve done in the past. Model years should then contain multiple orbits (ideally a whole number of them), such that we’re working with data over a broader length of time and we’re not filling up hard drive space with tons of output files. There’s no particular restriction on how many months to include per year in this case, but we should still probably have at least 1 per orbit, and an even number of NSTPW intervals per month.
Importing Topography
ExoPlaSim reads topography from a pair of .sra files: one is
a binary land/sea mask, indicating which cells are to be read as land surface,
and which are sea; and the other contains elevation data in the form of
“geopotential height”, which is just the elevation in meters multiplied by the
acceleration of gravity in meters/second2. The .sra files are just
strings of data values, but inputting them manually each time would get pretty
tedious. Fortunately, friend of the blog Alex (again) has put together a script that
can convert greyscale heightmaps to .sra files.
To use this function, first prepare a greyscale heightmap of your world, with whiter areas representing higher elevation, on a linear scale. If you’re using paint.net (though that’s only available on Windows, so you’d have to switch between operating systems), you can expand the colors window, go to the “HSV” section on the lower right, set the “S” slider to “0”, and use the “V” slider to set elevation: so for example, you could draw in the oceans as “0” (completely black), draw in your highest peaks as “100” (completely white), and then somewhere at half the elevation of your highest peaks as “50”.
(GIMP, which can run on linux, should have similar functionality, but the scripts we'll use in a bit don't seem to like to take image files produced by GIMP as inputs, for reasons I haven't quite pinned down).
It’s not vital that you use the full range, though; you could set your highest peak at “80” and your oceans at “20”, for example—though you’ll need to know the greyscale value of your oceans later, so it’s probably best to keep them at “0” for the most part with the land surface scaling linearly from 0 to its maximum value. And there’s no need to mark out underwater bathymetry—it may even cause issues with the climate model—so just use a flat ocean surface. Here’s what the result looks like for Teacup Ae:
We'll explore how to construct more detailed greyscale heightmaps in a later post, but for now such a rough sketch will do fine for the low resolution of the climate model.
Next, make sure the whole map is sized properly. The map should be in an equirectangular projection—with a 2:1 width:height ratio, and all lines of latitude and longitude equally spaced—and it should be an even multiple of its target resolution in pixels. So, for example, if you want to use the T21 resolution in exoplasim, which is 32 cells tall by 64 wide, then you’ll have to use an image that is some multiple of 32 pixels tall, and twice as many pixels wide. The above image, for example, is 512 pixels tall by 1,024 pixels wide.
Save the image (any common filetype should do, I’m using .png).
To convert the image to sra files, you can use Alex's tool, and conveniently make your script at the same time (you can also reuse the same sra files between scripts for the same terrain). If you do so, you can skip the rest of this section.
There's also a standalone python script you can use in your linux partition. As this post was written before the above tool was available, I've written a whole tutorial for it. I no longer recommend this approach (in particular, it won't include any later bugfixes bundled in the above tool), but I'll leave the tutorial in place for now:
Go into your linux partition and download the script Image2sra2.0.3.py, which can be found here (alongside a couple others I'll discuss later). Place it in your “Home” directory alongside the heightmap image, and then open Konsole and type in:
python3 Image2sra2.0.3.py
(or whatever version of the script you have, should it be updated in the future.)
You’ll then receive a few prompts in the konsole window. Most are self-explanatory, but just to be sure we’re on the same page:
First, you’ll need to input the path of your heightmap file; if the file is in the “Home” directory alongside the script, you can just use its name (you don't need to place it in quotes or anything, but do include the filetype suffix). The script will then say if it found the file; if not, try again.
Next, you’ll be prompted on whether or not to include any
oceans in the land/sea mask; if you input n, the script will fill in all
cells as “land”, regardless of elevation—this would be appropriate for all-land
planets. Otherwise, you’ll then be prompted on the level of your oceans on your
heightmap on a 0 to 255 scale of brightness; if you marked them black as
recommended, this should just be 0.
Next, you’ll have to input your highest elevation in meters,
measured relative to the lowest elevation on the map. The image is scaled
vertically before the resolution is reduced, so input the highest elevation on
your heightmap even if it only occupies a single pixel.
Next, you’ll have to put in the acceleration of gravity on your planet in meters/second2. This should be the same as in your model configuration (if you intend to test different levels of gravity for a planet, you'll either have to make new .sra files or use the orography parameter to alter topography by the inverse of the you're altering gravity by).
Next, you’ll be prompted on a debug option: if you select y, when the script completes it will output images showing the areas marked as land or sea at both the resolution of the input image, and that of the output files; this helps to check if there were any issues with how the script interpreted your image. Note that, while this script will mark partial land cover (e.g. a cell with 60% land cover will be marked as 0.6) and ExoPlaSim accepts data in that form, it appears that the data is internally treated as binary: cells below 0.5 land cover will be modeled as fully ocean, and others as fully land.
The script will then spend a little time interpreting your heightmap, and when done prompt you on the “latitude resolution”. This is the height of the climate model resolution; so for T21 it will be 32, for T42 it will be 64, etc.
If your image has the proper resolution to allow for this, the script will then spend a little time downsampling your image, and then finally ask you to give a name for the output files.
It will then output a pair of properly formatted .sra files in its directory; the file ending in 0129.sra contains your topography data, and the one ending in 0172.sra contains the land/sea mask. You can use the topomap and landmap parameters in the configure command of your model script to input these into the model.
Interpreting the Output
There are a few different ways to look at the output of the model, and if you’re not afraid of learning some code then you may want to look into using the included matplotlib functionality. For the rest of us, though, we can look at the data in the netCDF output files using Panoply, which you can download here.
Unzip and place the folder wherever convenient, click the "panoply.sh” file, and choose the option to “execute” (if you don’t get the option and it just opens as a text file, right-click on it, select “properties”, go to the “Permissions” tab and check “Is executable”, then try again). That should open a screen like this (you may have to give it a minute):
You can navigate to a netCDF file you want to look at, and select “Open”. This will bring up a list of output variables. There are a lot here, most meaningful only to climatologists, but you’ll probably be most interested in:
- cl: cloud area fraction in layer: the fraction of each cell covered in clouds at each atmospheric layer, on average
- clt: cloud area fraction: the total cloud area fraction across all layers.
- czen: cosine solar zenith angle: a representation of how high the sun is at midday; acos(czen) will give it to you in degrees.
- glac: glacier cover
- grnz: ground geopotential: the model topography, to use as a reference.
- maxt: maximum temperature
- mint: minimum temperature
- pr: total precipitation
- prsn: snowfall
- ps: surface air pressure
- sic: sea ice cover: as a fraction of area
- sit: sea ice thickness
- snd: surface snow thickness
- wnd: wind speed
- ta: air temperature: in the atmosphere, broken down by each atmospheric layer
- tas: air temperature 2m: the air temperature at 2 meters above the surface, which I’ll use later for determining climate zones on land.
- ts:
surface temperature: I'll use this for determining sea climate zones.
- vegf: forest cover
- vegnpp: forest net primary production: this is the total mass of carbon converted from CO2 to organic compounds by photosynthesis and not ultimately consumed by the plants themselves. As I'll explain in later posts, this is a decent measure for roughly how much life a region can support and how much food it can produce.
Select a variable, press “Create Plot” at the top left, and accept the default longitude-latitude color contour plot, and it will produce a plot of that over your world’s surface (there will be a map of Earth overlayed by default, but you can turn that off in the “Overlays” tab, and go to “Edit” → “Preferences” to stop it turning on by default).
In the “Array(s)” tab you’ll see options for which month to display data from (it’ll show a specific timestep in that month, but the data has been averaged for the whole month). For some variables it’ll also show atmospheric layers; the highest-numbered layer (e.g., layer 10 if your model had 10 layers) will be the one closest to the ground (the "sigma" value associated with each layer is the atmospheric pressure at the layer's center relative to the surface air pressure in that cell). If you switch layers and the plot is mostly one color, pressing “Fit to Data” should fix it. In the “Array(s)” tab you can also choose whether to interpolate the data—smoothing it between the cells in the ExoPlaSim model grid—or just show the raw data.
There are numerous options in Panoply for displaying data in different ways. To name just a few options:
- The “Scale” tab includes various options for different color
scales to use for the plot, and allows you to adjust the endpoints of the scale and the map key.
- The “Grid” tab allows you to alter the map projection. I’ll
discuss map projections at length in a later post, but a couple good options are
“Equirectangular”, which can be projected onto a globe in programs like GPlates and
MapToGlobe; “Mollweide”, a popular equal-area projection that I’ve used in the
past; and “Winkel-Tripel”, a popular compromise projection. You can also adjust the central longitude; if you want it to look the same as your original topography map, set this to 180 °E.
- The "Overlays" tab can be used to overlay transparent images on these maps, such as coastlines. Use "File" > "Open" to select such an image and then you can place it as an overlay, like so (note that you may have to offset the image first by 180°, and that you could probably get a cleaner appearance with a shapefile produced from a vector program, rather than the one I did here quickly in paint.net):
- In addition to the longitude-latitude plot, you can also
produce a plot of zonal averages (showing the average for some variable across
latitude) and use a line plot to chart the variable for one location (or a
zonal average again) across the year.
- You can also combine plots, which is useful for mapping out
wind. First make a plot of ua, eastward wind, and then select va,
northward wind, and press “Combine Plot” and select the existing ua plot. In
the “Array(s)” tab, select “Vector Magnitude” for your plot. The plot will now
be populated with arrows showing the wind direction across the surface, with
the color shading now showing the wind speed. You can tweak with the reference
value in the “Vectors” tab to adjust their size.
- Finally, you can export these images, either alone, or
together as an animation with “File” → “Export Animation…”, either as an MP4
video or a series of images that you can stitch together into a gif using tools
like ezgif.
- First, it will ask you to input netCDF files: you can either point it directly to a file or a folder, in which case it will find all files inside it with the .nc type (so only do this with a folder containing the last few years you want averaged together, not the whole model run). It will keep prompting you until you type in stop. You can just input a single file if you want to use the other features here rather than averaging together multiple files.
- Next, it will ask if you want to offset months, allowing you to shift forward or back what month the file starts on. The Image2sra script tends to create models that effectively start in November (i.e. around 2/12 of the year before winter solstice) so for a 12-month output an offset of 2 will shift the file to start in January. You can also offset back with negative numbers, so long as the magnitude of offset is not more than a full year. Otherwise just put in 0 for no offset.
- Next, it will ask if you want to rotate latitudes. This will convert the file's longitudes from the [0, 360) range ExoPlaSim outputs to a [-180,180) range with the new 0 longitude where the 180 longitude used to be. This will make the Panoply maps properly centered (so you don't have to use offset overlays).
- Next, it will ask if you want to produce annual averages as well. This will produce an additional netCDF file with the same averaged data, but now all averaged to single annual averages; so rather than monthly averages for temperature, precipitation, etc, there will be a single average over all months.
- Finally, it will ask you to give a name for the output; the annual average will have "_ann_av" appended.
The Koppen Zone Script
This is a script I wrote in Python to read the netCDF files
output from ExoPlaSim and interpret the climate data within them to produce
maps of Koppen climate zones for your world. You can find it here. In addition to python, it depends on the netCDF4,
numpy, scipy, and PIL packages (all of which should already be installed if you’ve
been following the tutorial). You modify and share this script if you like, but please link back to worldbuildingpasta.blogspot.com and indicate any changes.· I’ll explain the use of defaultcolor.ini; for now, it’s not necessary for basic use of the script.
Though the script is intended to be rather straightforward,
there are a number of options and features that may require more explanation.
Let’s start with the most basic use. For convenience, place koppenpasta.py and
the NetCDF file you wish it to interpret together in the “Home” directory. In
Konsole, type:
python3 koppenpasta.py
Once it starts, it’ll prompt you to input the path to your input file:
If they’re in the same directory, as recommended, you can just input its name (including .nc).
As of version 1.1, you can now also enter a directory (i.e. the name of a folder) and the script will find every file with the ".nc" type in that folder and take them as inputs, reporting their names in konsole as it finds them. So, for example, if you have a folder called "myModel" containing the last 10 years of output for your model, typing in myModel will load up all those files. I'll explain how the script handles multiple input files shortly.
If it finds the file, it will then prompt you on the advanced setup:
For now, respond n to skip.
The script will then run, loading data from the input file,
interpreting it, and drawing it out to an image file, named “output.png” by
default. It'll then ask if you want to run again with different configuration options, but again you can respond n for now
Once the script reports completion, you should be able to find that file in the same directory as the script. It should look something like this (you may have to zoom in a bit when you open it):
This is a map of your world’s climate zones at the same resolution as the climate model (in an equirectangular projection). A bit blocky, but that’s the limitation of the model.
Now that we’ve got that down, let’s go back to see what
options become available if you answer y to the “Advanced setup” prompt. Each
of these is accompanied by a short explanation in Konsole, but I’ll describe
their function and intended use in a little more detail here. Most of these
prompts are numbered lists, with each number keyed to an option such that you
can select an option by inputting the corresponding number. 0 is always the
default option (and all the (y/n) prompts will also interpret 0 as “no”,
for convenience).
Allows you to add more netCDF files as input. If you answer y you can specify more input files, just as you specified the first. Enter as
many as you like, and then type stop to indicate there are no more files (for now, this doesn't work with directories like the first prompt does).
The script will then average the data from all these files together, such that
for each cell of the climate model, it finds the average climate for each month
of the year across that period, and then uses that for determining climate
zones. A map produced from one year’s data is fine to get a quick sense of
climate, but averaging together data like this gives a better picture of
long-term climate and ensures the output isn’t biased by one year’s random
variation (e.g. an otherwise wet area that happened to have a drought in the
last year of the simulation might be marked as arid if you were using data from
only that year) so I recommend doing this for any final outputs.
To work properly, you should put in only files from the same model run that
share the same topography, resolution, and number of months. To make sure all
your input are from after reaching equilibrium, you should also try to use as
many years as the baseline in your runtobalance command (e.g. if you use a
baseline of 10, only use the last 10 years of the model output)—though you
could also restart the model and run it further with the same parameters to
produce more output for increased accuracy.
I’ll explain saving and loading configs later.
Determines the set of climate zones to use on land. By default the script finds the whole set of 31 climate zones, like so:
But you can also exclude the Aw/As distinction (as many sources do);
Find only the reduced set of 14 zones used in Part VIb and many other worldbuilding tutorials;
Find “seasonless” zones—in this case, the script will average data from all months together and find climate zones using only that averaged data, marking out only the 9 Koppen zones that are possible without seasonal variation;
 |
| I've also used seasonless seas here, but you can choose the behavior for land and sea climate zones independently. Naturally this wouldn't actually be sensible to do with this model of Teacup Ae. |
Or just mark out the 5 Koppen groups:
The reduced sets may be easier to read for people less familiar with the Koppen system, and also make for easier comparisons between different climate scenarios. The seasonless zones are appropriate for worlds with no obliquity or eccentricity, or very short orbits.
Finally, there is an experimental option to mark out an approximation of Holdridge Life Zones. This is an alternative climate zone scheme that doesn’t depend so much on seasonal variations.
Typically these are defined by 3 parameters: total annual precipitation (don’t worry, the script will account for different year lengths), annual average biotemperature (average of temperature except that any temperatures below 0 °C are counted as 0 °C, and those above 30 °C are counted as 30 °C), and potential evapotranspiration (the maximum amount of water that could evaporate or be transpired by plant life, were there limitless water in the soil).
However, there’s a lot of variation in exactly how exactly these parameters are used to define the zones with no single standard, and ultimately you can approximate the system using just 2 of them, though you will lose some detail in the boundaries between zones. Potential evapotranspiration is pretty difficult to approximate, so for the moment I’m only using precipitation and biotemperature, following the rough boundaries in this popular figure (and using the same colors):
 |
| Because I'm only using biotemperature and precipitation, the zones should actually appear as parallelograms on this chart, not hexagons. Peter Halasz, Wikimedia |
Also note that:
- For Holdridge zones there is no particular requirement for the number of months in the files read, and indeed the measurement of biotemperature will be more accurate the more data points it has to read from (i.e., more months).
- The definition of biotemperature presumes that photosynthesis is usually only active between 0 and 30 °C, which may not be accurate for alien life.
Determines the set of climate zones to use in the oceans. By default the script uses the sea zones I defined in Part VIb (though in this case using the sea ice data from ExoPlaSim rather than guessing the extent of sea ice from temperature) but as with land zones, there are options for reduced sets and “seasonless” zones using only data averaged across the year.
There’s also the option to exclude seas entirely, if you
have no oceans on your world and you marked all cells as “land” in your input
maps for ExoPlaSim (or used the desertplanet parameter).
Determines which colors to use to mark in Koppen climate zones in your final image. By default I use the same set of colors as in Part VIb, based off the maps on Wikipedia and already popular with worldbuilders. But I’ve also included an alternate set of colors used by some other sources:
And I’ve included a “true” color option; in this case, each zone is filled with the average color of that climate zone in satellite imagery of Earth. It’s far from a convincing depiction of a planet’s surface, but it gives you some idea of it, and in a later post we may explore how to use this as a starting point for constructing a more realistic “true color” map (though I may continue to tweak the colors in the meantime):
In addition, you can construct your own color lists. To do so, download defaultcolor.ini for use as a template. You can see that it contains a list of all the climate zones—listing each reduced set of zones separately, so they can be given different colors if desired—and the RGB values of their associated colors (currently, those values used in the default “blue rainforests” set).
You must retain all the climate zones and formatting in this list, but you can alter the rgb values to represent different colors, and then save the file with another name (but keep the “.ini” filetype). Back in the script, if you input “3” for the Color List selection, you’ll be prompted to input a filename, which you can do just as with input files at the start.
The script will read from this list after setup, and if there are no errors it will use it for constructing the climate zone map (if you see any black pixels in the output, something went wrong).
Determines how land and sea climate zones are output. By default, the script will read from the land/sea mask, show land climate zones in cells marked as land by the model, and show sea climate zones elsewhere, “blending” land and sea together in one map.
But alternatively, the script can also be set to output the land and climate zones as separate images (unless you chose to exclude sea zones before, in which case it will still just output the land map):
This way, you can scale these images up to higher resolution, cut one along the coastlines, and overlay it on the other:
So the “blended” option is more convenient for quick viewing, but the non-blended option allows you to create a better-looking map.
This lets you treat an input file as if it had fewer months for purposes of identifying climate zones by placing adjacent months into "bins" and averaging all data together. So, for example, if you took a file with 12 months, January to December, and set a bin size of "2", it will take all climate data from January and February, average it together, and treat that as one month, and do the same with March and April, May and June, etc.
This way if you have a planet with an especially long or short year, you can see how different approaches to defining "months" in the Koppen scheme affects the output.
This allows you to interpolate the climate data to higher resolution before determining climate zones. You can apply any rescaling factor that gives you an integer number of pixels: So, for example, if you ran your model at T21 resolution such that it has 32x64 cells, you could apply an interpolation factor of 4 to get an output with 128x256 pixels, or one of 1.5 to get an output with 48x96 pixels (you could also apply a factor of 0.5 to get 16x32 pixels, but I don’t know why you’d want to and I haven’t designed the script with that in mind), but if you tried to apply a factor of 2.7 (which would get 86.4x172.8 pixels) the script will probably crash, or otherwise produce weird output. Do note that high interpolation factors will significantly increase the amount of data the script has to handle, so it may take longer to complete.
Data is interpolated by the RectSphereBivariateSpline function included in the scipy software package (which should already have been installed alongside ExoPlaSim). In essence this works by attempting to construct a smooth curve that connects together all the data points in each row and column, and then picking out points in that curve to fill in the extra pixels (naturally because it’s doing this over a continuous 2d surface, the actual process is a little more complicated). This generally does a decent job of preserving fine details and smoothly transitioning between points of the surface, but ultimately this is just averaging together the existing data; this will not be as accurate as actual higher-resolution modeling, and in particular it can’t show the impact of topographical features smaller than the resolution of the climate model.
Still, because temperature and precipitation (and sea ice cover) data are individually interpolated before climate zones are determined, and because climate zones are defined by the overlap of several climate factors, these interpolated maps should be more accurate than anything we could produce by looking at the low-resolution climate maps and trying to guess what lies in between.
 |
| Climate interpolated up from T42 resolution (64x128) by a factor of 2 (top, 128x256), 4 (middle, 256x512), and 8 (bottom, 512x1024). |
You’ll note I didn’t try to interpolate the land/sea mask to higher resolution; there’s no real reason to if you presumably already have a higher-resolution map of your coastlines. I recommend you output unblended maps when using interpolation and splice them together yourself (as I did for the map at the top of the page), or use the "Blend by Topography Map" option I've now added.
If you choose to add interpolation, a couple further options will appear:
This corrects an issue with determining sea zones based on interpolated sea ice cover. ExoPlaSim only marks sea ice cover on the oceans, so when the script interpolates between ice-covered oceans and apparently ice-free land, a gap in sea ice will appear along the coasts. It’s pretty obvious where there should be ice, so it’s not so hard to just fill in the gap ourselves. But for convenience, I’ve added this option that, before interpolation, runs through the climate data and adds “dummy” sea ice to land cells whenever there is an adjacent ocean cell with sea ice.
This allows you to adjust the interpolated surface temperature based on higher-resolution topography than that used in the model. I'll explain how that works in a moment, but first, if you do choose this option, you'll then be prompted to upload a map:
Ideally you should use the same map as you used for creating the .sra files earlier.
You'll then be prompted to input the highest and lowest elevation and surface gravity, which again should be the same as used when inputting topography earlier. As of version 1.22, you'll now also be asked to provide a sea level, which will be used for determining sea climate zones (it should usually be the same as the lowest elevation but I figured I'd provide support in case a map has large basins below sea level).
So here's how it works:
Before interpolation, the script looks through the temperature data and topography data used by the climate model. For each cell, it looks at the neighboring 8 cells (5 at the poles) and compares their elevation: if there is at least a 100 meter difference between them (scaled by gravity, so more at lower gravity), it then compares their temperature data to determine a lapse rate; the rate at which temperature changes with elevation. It averages together the lapse rate found for each neighboring cell (ignoring those with an insufficient elevation difference), to determine an average lapse rate in that cell. Lapse rates across the world are put together into a map, and this is repeated for each month.
Once all these lapse rates are collected together, a global average lapse rate is computed, and any cells that had too little elevation difference with all of their neighbors to determine a lapse rate (such as those in the open ocean) will be assigned this average. Finally, to smooth out any local oddities, all cells have their lapse rate averaged with their neighbors (though in such a way that excludes that global average assigned to cells without data; so if there are 2 cells, A and B, and A could be assigned a lapse rate but B had to use the global average, A will not consider B's lapse rate in its average but B will consider A's lapse rate).
Both this lapse rate map and the model's topography map are then interpolated up to higher resolution along with all the climate data. The higher-resolution topography map you've input is scaled down to the same resolution, if necessary (elevation is still properly scaled according to the highest and lowest points in the original resolution, and if using the "Blend by Topography Map" option land and sea are first determined in the original resolution and then pixels at the downscaled resolution are assigned as land and sea based on which was the majority of their original area). The script then checks that higher-resolution topography map against its interpolated topography map in every pixel. If there's a difference in elevation, it adjusts the temperature (in every month) according to the interpolated lapse rate. It also adjusts the surface temperature data used for ocean zones to reflect what they should be at sea level according to that lapse rate (it occurs to me now that this may not be ideal for planets with different oceans at different elevations, so I'll add a toggle for that in the future).
What this means is that if there's an isolated peak in your topography that was too small to appear in the low-resolution topography used by the model, the script will cool it down a little; if there's a small valley, it will warm it up a little. And it'll do so based on the variation of temperature with elevation in the model.
 |
| Interpolated climate maps of a model of Earth without (top) and with (bottom) the temperature adjustment. |
Based on tests with Earth's topography, the result is far from perfect: mountains generally stand out more as colder regions, but in general still aren't cold enough; and yet a few patches are too cold (in particular, the Tibetan plateau should be pretty much all tundra, not a patchwork of tundra, ice cap, and continental climates). It's hard to say exactly what the issue here is; it could be inaccuracies in ExoPlaSim or insufficient data for my approach to finding lapse rate to work well, but at least partially it probably comes down using linear lapse rate in each cell being a very simplistic representation of how air motion around mountains actually affects surface temperature.
Still, it is an improvement, and at the very least it gives the map some nice added texture.
This gives you the option to configure the precise definitions of several climate zones. By default, the script uses the same definitions you can find on Wikipedia. For convenience, here’s the quick version (different month and year lengths are automatically compensated for in determining precipitation thresholds; “minimum” and “maximum” are selected from monthly averages, not the actual extrema for the entire year):
- A: minimum temperature > 18 °C
- Af: minimum precipitation > 60 mm/month
- Am: 60 mm/month > minimum precipitation > (100 – total annual precipitation / 25)
- Aw: minimum precipitation < (100 – total annual precipitation / 25) and total summer precipitation > total winter precipitation
- As: minimum precipitation < (100 – total annual precipitation / 25) and total summer precipitation < total winter precipitation
- B: total annual precipitation < (average temperature in °C) * 20 + (280 if >70% precipitation in summer, 140 if 30-70% precipitation in summer, 0 otherwise)
- BW: total annual precipitation < B threshold / 2
- BWh: minimum temperature > 0 °C
- BWk: minimum temperature < 0 °C
- BS: total annual precipitation > B threshold / 2
- BSh: minimum temperature > 0 °C
- BSk: minimum temperature < 0 °C
- C: 18 °C > minimum temperature > 0 °C and maximum temperature > 10 °C
- Cw: maximum summer precipitation > 10 * minimum winter precipitation
- Cwa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Cwb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Cwc: months above 10 °C < 4
- Cs: minimum summer precipitation < 30 mm/ month and < minimum winter precipitation and < maximum winter precipitation / 3
- Csa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Csb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Csc: months above 10 °C < 4
- Cf: meets neither Cw or Cs definition
- Cfa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Cfb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Cfc: months above 10 °C < 4
- D: minimum temperature < 0 °C and maximum temperature > 10 °C
- Dw: maximum summer precipitation > 10 * minimum winter precipitation
- Dwa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Dwb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Dwc: months above 10 °C < 4 and minimum temperature > -38 °C
- Dwd: months above 10 °C < 4 and minimum temperature < -38 °C
- Ds: minimum summer precipitation < 30 mm/ month and < minimum winter precipitation and < maximum winter precipitation / 3
- Dsa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Dsb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Dsc: months above 10 °C < 4 and minimum temperature > -38 °C
- Dsd: months above 10 °C < 4 and minimum temperature < -38 °C
- Df: meets neither Cw or Cs definition
- Dfa: maximum temperature > 22 °C and months above 10 °C ≥ 4
- Dfb: maximum temperature < 22 °C and months above 10 °C ≥ 4
- Dfc: months above 10 °C < 4 and minimum temperature > -38 °C
- Dfd: months above 10 °C < 4 and minimum temperature < -38 °C
- E: maximum temperature < 10 °C
- ET: maximum temperature > 0 °C
- EF: maximum temperature < 0 °C
However, some boundaries are marked a bit differently in other sources, so I’ve given you the option to decide whether to use a few of the most popular alternative definitions. They’re all fairly straightforward, so I won’t explain them further here apart from a couple:
First, the definition of summer: Traditionally summer has been defined in the Koppen scheme as the “high-sun" months, i.e. the half of the year when the sun reaches highest in the sky at its zenith; thus, summer covers the same period across each hemisphere. But this isn’t always the best representation of local climate, and for our purposes would be a very poor representation of seasons on a world with high eccentricity and low obliquity. Thus the modern standard is to define summer as the half of the year with the highest average temperature at any given location. This is the default behavior for this script, but you can optionally use the “high-sun” definition instead.
Second, a small issue with the standard definitions is that they tend to assume that hot and dry seasons correspond neatly to summer and winter, which might not be the case with, say, high-obliquity worlds. It is, for example, technically possible for a region to be satisfy the requirements for both Cs and Cw zones (or Ds and Dw). To clear up this ambiguity, I’ve added the additional requirement that Cs and Ds zones must have more total rain in winter than summer, but any region that does meet that and the other requirements will be marked as Cs or Ds even if they also meet the requirement for Cw/Dw zones. But alternatively, you can remove this requirement and select the priority for assigning Cs/Ds and Cw/Dw zones.
This allows you to save all the advanced options as a .ini file. When using the script later, you can load that config file when prompted near the start of advanced setup—just as with the input files and custom color list. The script will load all the setup options from the config file, and skip the rest of setup. Note that:
- The name of the input and output files are not saved in the config file, these will have to be input every time.
- If a custom color list is used, this is saved by the config, but if it cannot be found then you will be prompted to input a new file or location, or choose one of the default color lists (this choice is not saved to the config file).
- The only way to alter a config file after creation is manually editing it. It should be pretty clear which parameters are keyed to which setup options.
Finally, you can choose your own name for the output file. You cannot change the filetype, though, it is only output as a .png.
I've also now added an option after the script completes to run it again with the same input files and different configuration options, in case you want to try a few different map types.
And as a final note for those more interesting in scripting, I've now configured both the koppenpasta.py script and the eps_avg.py script I mentioned earlier such that they can be imported into python scripts and run as functions; see the readme for details.
Dialing in the Climate
Climate is tricky and chaotic and has many subtle influences, and even just ballparking the average temperature of a habitable planet given irradiation, solar temperature, and CO2 levels can be devilishly complicated. So ultimately we’re just going to have to make a lot of guesses until we arrive at something like what we’re looking for.
Complicating the matter, finding a desired climate may be harder than just putting in the right initial conditions. A fairly common finding of climate models is that when climate forcings are altered, there are often regions of instability, where a small shift in forcing will cause the climate to suddenly jump to a very different state. For Earthlike worlds, this is often due to ice-albedo feedback: An ice-covered world may, with a small increase in sunlight or greenhouse heating, begin to melt, and that melting will cause the planet to be less reflective and so absorb more sunlight, and so become warmer and melt more ice, and so on until the ice is completely lost. It takes more heating to begin melting the ice than it does to continue melting it afterwards, so there’s no set of initial conditions that will allow the world to transition directly from a snowball to a partially-thawed world with surviving polar ice caps (in reality the actual dynamics of snowball recovery may vary between worlds and circumstances, this is just an illustrative example).
However, this region of instability may shift depending on
the initial state of the planet: It may be impossible to transition directly
from the snowball to a partially thawed state, but once the planet is thawed,
we may be able to gradually cool it to such a state. Enough cooling will
eventually make it unstable again, freezing to snowball, and there may be a
range of climate states not accessible by either warming a cold world or
cooling a warm world; e.g. once the ice caps reach some latitude, it may be
impossible to prevent the whole world freezing over (again, the transitions may
be more complex in reality).
But still, there are certain states that are possible, but can only be accessed from certain starting conditions. This is a phenomenon known as hysteresis: the current state of the system depends not only on its current parameters, but on the system’s history.
 |
| Common examples of hysteresis: ice caps on low-obliquity planets (top) may only be accessible from an initially ice-free state, and ice belts on high-obliquity planets (bottom) may only be accessible from an initial snowball state. |
ExoPlaSim simulates ice-albedo feedback (though the lack of glacier spreading and some related feedbacks may make it somewhat weaker than in reality), so we can expect it to display some cases of hysteresis, and thus achieving certain climate states may require more control than just setting the initial parameters. By default, models begin with global temperatures of 247 K (-25 °C), but because there are no initial glaciers or snow, there isn’t much “inertia” to this cold state and so it can warm fairly rapidly and it’s even sometimes possible to put the model straight into an intermediate state with partial glacier cover. But to reach certain climate states it may be necessary to set the initial configuration to achieve either a completely cold (ice-covered) or warm (ice-free) state, then alter them to an intermediate state.
You can achieve this by running new models off restart files, but you can also alter the parameters of a model while it’s running by using the “modify” function, which allows you to change any of the parameters in the “configure” function, and then continuing to run the model afterwards (the runtobalance function doesn't work too well with this, as it seems to search the entire model history for balance rather than just the time since the command was executed; thus running to balance multiple times is best done by running a new model off a restart file). While you’re at it, you can also add a “finalize” or “save” function to save the state of the model at this point (for the “finalize” function, you must set “clean=False” or the model won’t be able to continue running, and I’d also recommend setting “allyears=False” to save on hard drive space and choosing a different name from your final output)
So a typical such script may look something like this:
There’s a few cool tricks we can run with this kind of approach; I'll attach a script to the end of this post that iteratively modifies the model’s CO2 levels until it balances within a desired temperature range.
For modeling Teacup Ae, I started with the parameters I had been using previously; 25° obliquity, 0.1 eccentricity, longitude of periapsis of 30°, and global average temperature of 16 °C, but because Ae has a significantly shorter year (just over 1/3 of Earth's), seasons are significantly weaker and many high-latitude regions were colder than Clima-Sim had suggested. So I increased obliquity to 30°, increased the longitude of periapsis back up to 80°, and increased global average temperature to 20 °C. To review, here's the result:
Also, as a final note: it’s generally a good idea to run some T21 models first to get a sense of the world’s climate before moving on to higher-resolution T42 or (if you’re ambitious and have a good machine) T63, but note that there can be a significant difference between models at these resolutions, especially if you’re working with more exotic worlds. My model for Teacup, for example, required 0.825 bar of CO2 to balance at an average temperature of 16 °C at T21 resolution, but only 0.011 bar at T42 resolution. I don’t think there’s as much of a difference between T42 and T63 resolution, but I haven’t really been able to test it much.
Advanced Use of ExoPlaSim
We’ve now covered all the essential use of ExoPlaSim, and you should know enough to model most reasonable climate scenarios. But just as a point of interest, I’ll list off some options for using ExoPlaSim in ways beyond these normal cases. For now these are mostly just suggestions that you’d have to investigate on your own, but as I investigate different options in the future, I’ll update this section.
Further Posprocessor Configuration
There are a few more options for configuring the output files with the cfgpostprocessor command. In particular, it may be useful to output zonal averages (average values within each row of the climate grid, allowing you to construct a profile of some variable across latitudes). You can also limit the variables written to the output, rather than just outputting them all by default (variable codes here) which may help reduce the file sizes. Finally, rather than inputting a number of months for the times parameter, you could input a list of output times (written as fractions of the year, within paranthesis, separated by commas, e.g. (0, 0.3, 0.5, 0.7)). This doesn’t exactly match the spirit of the “months” used for Koppen zones, but it can be useful if you want to look at data for a particular part of the year (e.g., near periapsis for a highly eccentric orbit).
Constructing Atmospheric Profiles
Atmospheric layers in the output are all accompanied by a sigma level, indicating their pressure relative to surface pressure (not sea level pressure), so you can determine their value by multiplying sigma by the surface pressure in that cell. Converting atmospheric pressure to altitude is not always straightforward. The simplest approach would be to determine a scale height for the planet and construct a single altitude/air pressure function across the whole surface.
A more accurate approach may be to use the hypsometric equation to determine the vertical thickness of each layer, and add them together (with surface elevation) to determine the altitude of higher layers. The tricky bit there is determining virtual temperature; I believe using air temperature with the “liquid water content” value in the output should allow for a good approximation.
Carbon-Silicate Cycling
Generally speaking you can assume there is some level of volcanic activity that will cause the carbon-silicate cycle to balance to give you any desired level of CO2, and then just say that your world happens to currently have that level of volcanism (though bearing in mind some general considerations for how the carbon-silicate cycle shifts as the planet evolves).
But if you really wanted to, ExoPlaSim does include options for modelling the carbon-silicate cycle. If you add “co2weathering = True” in the configure step, the program will attempt to model the rate at which CO2 is removed from the atmosphere by weathering (there are a couple other options you can find in the documentation). Realistically you couldn’t run a model for long enough for the carbonate-silicate cycle to play out and equilibriate, but what you could potentially do is run a model until the climate balances, determine the rate of change in CO2 based on the weathering rate and an assumed CO2 outgassing rate, extrapolate that out for a few thousand years, and then restart the model with adjusted CO2 levels, and iterate in that way until you reach an equilibrium in CO2 levels. Some research along these lines has been done with earlier versions of PlaSim.
Storm Climatology
ExoPlaSim also includes options for studying the potential for hurricane-like storms to form by adding the parameter stormclim = True. This will roughly double the runtime of the model (so I recommend only turning it on after reaching equilibrium and then running for a short time), but adds some parameters describing the likelihood of storms to the output. I’m not too familiar with exactly how to interpret these, but “Genesis Potential Index” appears to be an attempt to summarize the overall likelihood for large storms to form at different points across the surface.
There are additional options to allow high Genesis Potential to trigger a “High Cadence” mode, which will record more data—in essence allowing you to track the development of individual storms—but I’m not too familiar with the process of implementing and interpreting this, and it’s unlikely to work particularly well at T21/T42 resolutions anyway.
Detailed Stellar Spectrum
Exoplasim can read from a more detailed stellar spectrum than the rough adjustment by star temperature it generally uses. To do so, use the Phoenix stellar spectrum simulation and use the commands here to convert it for use in ExoPlaSim here (to run python in command line as suggested, type in python3.6 in Konsole). You can then import it into a model using the starspec parameter in your configure command, rather than startemp.
But honestly, given the simplicity of ExoPlaSim’s internal handling of light spectra, I haven’t attempted this myself so far.
Other Climate Models
I’m not aware of any other climate models that are anywhere near as easy to install and use as ExoPlaSim (yes, all the above is “easy” by the standards of these models), and many couldn’t run in a reasonable time on a personal computer even if got them installed, but just for reference, here’s a list of others I’ve come across that may be of interest for some specific uses:
VPlanet
Not a full GCM, but a group of tools for modelling the atmospheric and orbital evolution of worlds in a variety of scenarios, with basic climate modelling—in essence, it models a world’s surface in 1 dimension from pole to pole, not a 2-dimensional grid, so it’s not as detailed or accurate but will run a lot faster (though it should actually give a more accurate estimate for the greenhouse effect of high CO2 levels). The documentation is extensive but a bit unfocused, but there are many examples to follow and use as templates. If you don’t want to take the time to run an ExoPlaSim model, or you want to explore some scenarios outside its ability to model, this may be a good option.
ROCKE-3D
Short for "Resolving Orbital and Climate Keys of Earth and Extraterrestrial Environments with Dynamics". This is essentially the gold standard of modern exoplanet climate modelling, a comprehensive model specifically designed to avoid any assumptions specific to Earth, and adapt to a broad variety of scenarios. Unfortunately, it runs orders of magnitude slower than ExoPlaSim, and the inclusion of deep ocean circulation means it may need to simulate thousands of years rather than just decades. If you really want the best climate model available and you have access to a powerful, dedicated server, then this may be your best option.
Isca
A GCM that, similarly to ExoPlaSim, aims to be intermediate in complexity between simple models like VPlanet and advanced ones like ROCKE-3D. For the moment, it appears that the documentation and model are still under development, but it may be worth keeping an eye on in the future.
Oasis
An in-development GPU-accelerated GCM, that apparently is intended to be fairly scalable for different computers. We’ll see how the final result turns out, but it’s worth keeping an eye on.
Script Templates
To end off this tutorial, here's a couple templates you can use to create your own scripts. First, a basic script with all the configuration options available, set to Earthlike settings, so you can delete those you don't want and adjust those you do:
Here's essentially the same script but I've spaced it out a bit more and added some basic info, if you have trouble remembering what each parameter does:
And here's a script I've been working on that adjusts the script's parameters as its running to try and achieve a stable temperature within half a degree of a desired goal:
If you're using a very different planet from Earth, be sure to alter the level and adjust parameters as appropriate, and the length of the model runs. This script could also be pretty easily altered to adjust, say, flux instead of CO2 levels (by changing the modify step). The script will also save the ouput between each run, with a text file called "modelreport.txt" that allows you to keep track of how it's progressing. Note that this can end up taking significantly longer than just running to balance on the initial parameters.
That's all for now. I may continue to add more notes as I continue experimenting with different ways to use ExoPlaSim.
That was a very good tutorial, but I seem to run into a trouble, I am using the virtual machine method, and when I use the kate program input, it doesn't recognize it.
ReplyDeleteAh, Kate probably isn't installed with the virtual machine version then. I'd suggest building the script in windows with something like notepad++ and then moving it into the virtual machine.
DeleteFor the .sra file format, what are the meanings of the elements in the first row? It looks like this converter script just dumps out a '11111111' for the third element. It's concerning me a little as the example .sra files do not have that number and it seems variable. Also, the land mask isn't clamped to 0 or 1 in the example files.
ReplyDeleteI suspect that first number was used for some sort of calendar setting in past versions of plasim, but doesn't seem to have much function now (things like year length, number of months, and timing of periapsis are all set by model configuration in python, and the whole calendar system was recently rebuilt from scratch) so we just chose an arbitrary number to fill the space. It might be worth experimenting to see if it controls, say, the starting month of the model, but at any rate I'm pretty confident it doesn't cause any major issues.
DeleteWe had once thought that ExoPlaSim could handle partial land cover in its land/sea mask (based on those same example files), and the convertor should actually construct its land/sea mask in that way, but based on output files it appears that the model actually binarizes it internally, rounding to full land or full sea cover in each cell before starting.
Nice article! I am using the virtual machine method but when I try to run program.py, the 'permission denied' error shows up. The problem still persists after I reinstall the package like the tutorial suggests. Is there a way to resolve this issue?
DeleteTo be perfectly honest, I'm not sure how to deal with those issues and that's part of why I suggest the partition approach. I'll leave the comment up in case anyone else knows better.
DeleteYou need to put it your user folder. Such as \\wsl$\openSUSE-Leap-15.3\home\UserNameHere
DeleteThen each run you will need to delete the generated folder because it wont have permission to delete it on its own.
My compilation always crashes almost immediately, saying that ExoPlaSim has begun producing garbage. What am I doing wrong?
ReplyDelete"Exoplasim has begun producing garbage" is something of a catchall for something causing a crash while running. It may be specific to the model you're trying to run--you could maybe try running a very simple model with no topography to see how that works. If that's not the issue, I'd need to know more about the crash and how you've configured it to say more.
DeleteSpecifically, I'm trying to follow the instructions on your blog "Worldbuilding Pasta," in the section following the installation of ExoPlaSim. I've created the simple program "program.py" on Kate and specified the number of cores (12), but every time I run it, it always gives me the message of having "produced garbage." I've tried changing the cores to 4, which runs a bit longer but still produces the same final result eventually. Would I be able to chat with you on Messenger to resolve this? Having this program perform properly is a very high priority for me, and I'd definitely contribute generously on Patreon once I have the program running properly. (Name is Peter Toth; I believe I sent you a message on November 23 of last year.) Thanks immensely, Nikolai!
DeleteLately I've tried to copy the template at the bottom of the tutorial and run it, having creating .sra files for the topography. This is the error message I keep getting just before the program crashes:
DeleteDuring handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "programtwo.py", line 24, in
model.runtobalance(baseline=10, maxyears=300, minyears=20, timelimit=480, clean=True)
After that, the program states: "ExoPlaSim has crashed or begun producing garbage."
Is there any way to configure the program differently in line 24 that wouldn't produce a crash?
Is this still Peter? All that line means is that line 24 is the command that tells the model to run, so if something--anything--causes the model to crash, that is the line the script is at when the issue happens, there's nothing wrong with the line itself. If there are other errors above that message, those are probably more diagnostic; Though if this only happened when you added topography, my best guess is that it may be too steep somewhere.
DeleteGreat stuff! On attempting to run a model at T63, Konsole gave me the following readout after the first year:
ReplyDelete*** FFT does not support n = 192 ***
Following resolutions may be used:
----------------------------------
NLON= 8 NLAT= 4 NTRU= 2
NLON= 16 NLAT= 8 NTRU= 5
NLON= 32 NLAT= 16 NTRU= 10
NLON= 48 NLAT= 24 NTRU= 16
NLON= 64 NLAT= 32 NTRU= 21
NLON= 96 NLAT= 48 NTRU= 32
NLON= 128 NLAT= 64 NTRU= 42
NLON= 256 NLAT= 128 NTRU= 85
NLON= 384 NLAT= 192 NTRU= 128
NLON= 512 NLAT= 256 NTRU= 170
NLON= 1024 NLAT= 512 NTRU= 341
NLON= 2048 NLAT= 1024 NTRU= 682
NLON= 4096 NLAT= 2048 NTRU= 1365
I'm guessing it is referring to the width. Any ideas?
I recently attempted a T63 run as well and ran into a similar issue. Best guess is that some part of the new postprocessor doesn't support that resolution; I think I'll actually throw an email to the dev to let them know. T85 should work, though, if that's any help.
DeleteThanks for the info. If I'm brave enough I'll give it a shot later.
DeleteAny info on whether or not this has been resolved?
DeleteThe latest exoplasim commit should have solved this, but I haven't had a chance to test it myself yet.
DeleteSeems like this hasn’t been fixed yet. Still getting the same error.
DeleteAdditionally, after attempting a T85 run overnight I found that the simulation had stopped running by morning. The Konsole output "Killed" instead of the program actually crashing. Any insight into this?
Delete@Anonymous: I've seen processes on linux get killed overnight without noticeable error. Linux operating systems have something called the OOM-Killer which kills heavier processes when the system starts running out of memory. I suspect that's what happened to you. It's too late to confirm that now, but you can look in the dmesg logs if it happens again to confirm, it will say something like "...Out of memory: kill process..." I do not know how to stop it.
DeleteWhen I try to run it in visual studio, it says "no module numpy" even though I have numpy installed
ReplyDeleteThat would probably be an issue with your particular python or visual studio install, I'm not sure because I don't really use visual studio much (does it even have a linux version? ExoPlaSim won't run on Windows)
DeleteI'd like to thank you for including the extra C02 scripts and what not. It's a great help for those of us who are less tech savvy!
ReplyDeleteI do have a question about their outputs. When running the script, why do the snapshot outputs look so different between the primary model_run folder and the extra model_runs the program creates when it tweaks the C02? E.g "MOST_SNAP.XXXXX.nc vs. the model.nc? When using the koppenpasta program to view them, the climates seem wildly different.
Also, in the model_run# folders, does the model_report.txt include the carbon in plants or just atmospheric carbon content?
Finally, how exactly do you start a model from a restart file? When I tried to designate one of the model_restart files from the aforementioned model_run# folders, EPS-IC doesn't seem to recognize them. Is it because it's missing a file type extension?
Thanks!
The snapshots folder contains data from particular timesteps, rather than averaged across them. So, for example, with the default settings the regular output files ("MOST.XXXXX.nc" or "model.nc") will contain temperature data averaged into months; each data point represented is an average of the temperature across the entire month. But the snapshots ("MOST_SNAP.XXXXX.nc") will contain temperature data from 24 specific points of time, one every 15 days; none of the time in between is included. The regular outputs, with averaged data, are preferable for making climate maps, but the snapshots might be interesting if you want to know, say, what the temperature variation is like at a particular time of day.
DeleteIf I remember right, the "model_report.txt" is just a file created by my scripts with very basic information on temperature and atmospheric CO2. I'm not sure the model is really capable of accounting for carbon exchange between the plants and atmosphere (it's not really significant at these timescales, and in steady-state system the net exchange should be zero).
You'd have to ask Ost about EPS-IC, I'm not much involved in its development. Restart files don't require any particular extension. You could just run the program without any restart file and then manually add one into the script it produces, it's just "restartfile = [path to the restart file]".
When I try to use the Image2sra converter I get the error:
ReplyDeletered_img = imread(infile)[:,:,0] #opens red channel
IndexError: too many indices for array: array is 2-dimensional, but 3 were indexed
I haven't altered anything to the files. This is my first time installing Linux on an old laptop & doing any of this kind of work, but I wanted to really get into this stuff. Do you have any idea what causes this or what I can do to find out?
This probably means that the image contains more pixel color data than the script is expecting, it's something I've encountered with images exported from GIMP before. Putting in the image in Paint.net and running the black and white filter over it has usually been reliable for me in producing the right images, but that program doesn't work on linux so it requires some jumping back and forth between operating systems. I think GIMP (and presumably similar programs like photoshop) also has an option in the menus somewhere to change the image color mode, so that may be worth playing around with.
DeleteTurns out my image was exported in the wrong color space (Not using RGB values), thanks for the help!
DeleteI seem to have run into another problem. The model seems to run properly for the most part until suddenly the "Fortran runtime warning: an array has been created" starts producing more elaborate results. After which it doesn't take long for it to produce the following error codes:
Delete"Fortran runtime warning: An array temporary was created for argument '_formal_183' of procedure 'mpputgp'
At line 793 of file plasim.f90
Fortran runtime warning: An array temporary was created for argument '_formal_183' of procedure 'mpputgp'
At line 792 of file plasim.f90
Fortran runtime warning: An array temporary was created for argument '_formal_183' of procedure 'mpputgp'
At line 793 of file plasim.f90
Fortran runtime warning: An array temporary was created for argument '_formal_183' of procedure 'mpputgp'
[ -e restart_dsnow ] && rm restart_dsnow
[ -e restart_xsnow ] && rm restart_xsnow
[ -e Abort_Message ] && exit 1
[ -e plasim_output ] && mv plasim_output MOST.00000
[ -e plasim_snapshot ] && mv plasim_snapshot MOST_SNAP.00000
[ -e plasim_diag ] && mv plasim_diag MOST_DIAG.00000
[ -e plasim_status ] && cp plasim_status plasim_restart
[ -e plasim_status ] && mv plasim_status MOST_REST.00000
[ -e restart_snow ] && mv restart_snow MOST_SNOW.00000
[ -e hurricane_indicators ] && mv hurricane_indicators MOST.00000.STORM
No module named 'exoplasim.pyfft'
'variables'
Error writing output to MOST.00000..npz; log written to postprocess.log
Going to stop here just in case......
Going to stop here just in case......
Traceback (most recent call last):
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 1085, in postprocess
pyburn.postprocess(inputfile,inputfile+self.extensions[ftype],logfile=log,
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/pyburn.py", line 3644, in postprocess
data = dataset(rawfile, variables, mode=mode,radius=radius,gravity=gravity,gascon=gascon,
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/pyburn.py", line 1348, in dataset
rawdata = readfile(filename)
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/pyburn.py", line 584, in readfile
import exoplasim.pyfft as pyfft
ModuleNotFoundError: No module named 'exoplasim.pyfft'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 1105, in postprocess
pyburn.postprocess(inputfile,inputfile+self.extension,logfile=log,namelist=namelist,
KeyError: 'variables'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 558, in runtobalance
timeavg=self.postprocess(dataname,None,
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 1127, in postprocess
if self.integritycheck("%s%s"%(inputfile,extension)):
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 1164, in integritycheck
ioe = self.postprocess(ncfile[:-3],"example.nl",crashifbroken=False)
File "/home/tom/Downloads/ExoPlaSim-master/exoplasim/__init__.py", line 1137, in postprocess
raise RuntimeError("Going to stop here just in case......")
RuntimeError: Going to stop here just in case......
It's probably something straightforward that I can't seem to make out due to my inexperience with Linux, but any help is appreciated.
The first part of this long message is the code working correctly. It doesn't break until No module named 'exoplasim.pyfft'. I don't know what that is but it seems like you are missing a file the program needs to run. Maybe try re-downloading everything or ensuring you have all of the packages? I am searching in my files for this exoplasim.pyfft, but haven't found it yet. There are three files named pyfft.f90, pyfft.so, etc in my exoplasim directory. Do you see those?
Deleteexoplasim.pyfft is created within the exoplasim directory during configuration (when it runs for the first time) based on some files installed with numpy, though those files don't seem to be installed reliably with latest versions of numpy. The best approach would be to complete uninstall exoplasim and numpy and remove their directories if theyr'e still there, and then reinstall, allowing the pip install exoplasim step to deal with numpy (it should use an older numpy version).
DeleteEven then the exoplasim.pyfft file won't always be created properly in configuration on VM installs of linux. Being very careful about doing everything in order and setting the permissions right might help, but frankly I'm not sure, not being a VM user myself.
Hi, thanks for making this documentation available to us, I had tried to use PlaSim before, but it never ran fast enough & there were many obstacles editing terrain...
ReplyDeleteI already had a working Linux VM on my windows machine so I went that route & ran the test code with no problems. I then modified the 2nd script template you provided with the relevant constants for my planet... but when I run, the postprocessing gives me this error. It isn't due to the model- I've tried turning on & off storm development, glaciers, topography and I still get the same issue. I have snapshot output in my cash folder that can be used in NetCDF, so I suspect the problem isn't with the map or inputs at all, which really confuses me as I didn't change any of the structure of the template & had no difficulty with the trial run. I checked the ExoPlaSim documentation & there is vague discussion of postprocessor error, but none that seems relevant here.
This is my error
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1107, in postprocess
gravity=self.gravity,gascon=self.gascon,**kwargs)
TypeError: postprocess() got multiple values for keyword argument 'variables'
I haven't really used Python before & wasn't familiar with a "keyword argument". Is there something I can do to fix this error that I have missed in my ignorance?
Thanks
Definitely a postprocessor issue, best guess is that it's either a formatting issue with the script or some kind of timekeeping problem, seeing more of the error report or the script might help me say more.
DeleteThis is my full error statement:
Deletepostprocess() got multiple values for keyword argument 'variables'
Error writing output to MOST.00000.npz; log written to postprocess.log
Going to stop here just in case......
mkdir: cannot create directory ‘/home/matoronui99/mar_crashed’: File exists
Traceback (most recent call last):
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1107, in postprocess
gravity=self.gravity,gascon=self.gascon,**kwargs)
TypeError: postprocess() got multiple values for keyword argument 'variables'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 594, in runtobalance
check=self.integritycheck(dataname+"%s"%self.extension)
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1164, in integritycheck
ioe = self.postprocess(ncfile[:-3],"example.nl",crashifbroken=False)
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1137, in postprocess
raise RuntimeError("Going to stop here just in case......")
RuntimeError: Going to stop here just in case......
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "marclim.py", line 59, in
timelimit=480, #maximum time to run, in minutes
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 638, in runtobalance
self._crash() #Bring in the cleaners
File "/home/matoronui99/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1704, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/matoronui99/mar_crashed/
I think I'm probably gonna have to see the full model script, as the error here seems to be pointing to the command to run the model, rather than the configuration step that is probably actually causing the issue.
DeleteI tried commenting the script that causes the error, but it is too long. I could send it to you if you would be interested in inspecting it. It may just be because I have no knowledge of Python, but if it proves to be something that can only happen to VM users, it may be an interesting advice/warning more generally.
DeleteInterestingly enough, I wrote another script based on the ExoPlaSim documentation, using run() and not runtobalance(), and it worked- until it had a runtime error 40 years in. But I think that may have happened because my computer switched networks, which seems to always cause my runs to crash.
As another comment, I wish it were possible to manually add glaciers of a certain height over only part of the globe. I tried running a model with the setting to start out the whole globe under a little ice, but obviously 1 m is not so resistant to melting, unlike the miles of ice that cover actual continental glaciers & persist during interglacials like in Antarctica & Greeland. Plus, it would help with convergence time, which is a serious limitation for me at 30-40 mins per year.
If you send the script to worldbuildingpasta@gmail.com I can look it over, sure.
DeleteI've asked the dev before about adding in initial glaciers, and in short, it is possible in principle but requires starting up a model and then altering the models running files; given that these files are basically just lists of data points, in practical terms this would probably amount to learning how those files are structured and then building a python script to interpret a map of glacial cover and format it into the right type of file. I can send back the dev's comments on the subject if you like, I just ended up deciding it wasn't worth the effort for me.
Did they ever get back to you? If so, did they ever find the problem? I seem to be having a similar issue.
DeleteHope this isn't too late - my ugly solution was to change the second pyburn postprocess call to be the same as the first one (not providing variables and namelist since those are already in the arguments apparently) and run with clean in the runtobalance call off.
DeleteGot through the test run fine, but when I went to do a real run I got this:
ReplyDeleteCommand '['mpiexec -np 4 most_plasim_t42_l10_p4.x']' returned non-zero exit status 136.
mkdir: cannot create directory ‘/home/dime/ExoplasimWorkspace/testmap_crashed’: File exists
Traceback (most recent call last):
File "/home/dime/.local/lib/python3.8/site-packages/exoplasim/__init__.py", line 521, in runtobalance
subprocess.run([self._exec+self.executable],shell=True,check=True,
File "/usr/lib/python3.8/subprocess.py", line 516, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['mpiexec -np 4 most_plasim_t42_l10_p4.x']' returned non-zero exit status 136.
followed by the normal crash message.
Here's the script I was running:
import exoplasim as exo
testmap = exo.Model(workdir="testmap_run", modelname="testmap", outputtype=".nc", resolution="T42", layers=10, ncpus=4,precision=8, crashtolerant=True)
testmap.configure(snapshots=960,fixedorbit=True,radius=1,landmap="testmap.sra_surf_0172.sra",topomap="testmap.sra_surf_0129.sra",pN2=0.7809,pO2=0.2095,pAr=0.0093,ozone=True,wetsoil=True,glaciers = {"toggle": True, "mindepth": 2, "initialh":-1})
testmap.cfgpostprocessor(times = 12)
testmap.exportcfg()
testmap.runtobalance(baseline=10, maxyears=100, minyears=10, crashifbroken=False, clean=True)
testmap.finalize('model_out', allyears=True, clean=True)
testmap.save()
ExoPlaSim can be a crashy program at the best of times. You should be able to find restart files inside the crashed folder, and restart the model a few years before the crash. If the crashing persists, adding physics filters or reducing the timestep may help.
DeleteWhat does a restart file actually look like? Regardless, the crash happens really quickly, and seemingly before the actual run given the lack of anything in the snapshots directory.
DeleteI finally figured out what the issue was. I was using https://topps.diku.dk/torbenm/maps.msp to make a map to test with. Thing is, it appends information about the map to the end of the generated bmp file so that a user can recreate it from the image file alone. Since the SRA converters used here weren't designed with this in mind, they interpreted that information and put it in the final SRA files. Then, Exoplasim crashed because of the invalid SRA files.
DeletePutting the map through a bmp to png converter seems to have fixed the problem, although just opening up the bmp in a text editor and removing the final bit should work fine.
...or at least this is what I THOUGHT was happening. The issue seems to have mysteriously returned now that I'm trying another map despite all off the necessary precautions being taken.
DeleteAfter getting some sleep, I did some more tests. All of these tests are done on the same PNG file unless otherwise noted.
Delete-This crash only occurs at T42 and above, T21 works fine.
-Setting orography to 0 still does not fix the issue, and removing the SRA file arguments from the configure() call still does.
-This bug occurs using either SRA generator.
-Using the debug feature, I don't notice any issues in the images.
-All of this holds true when using a different PNG file.
My conclusion from all of this is that the crash is still being caused by the SRA files being somehow improperly formatted and that the SRA generators here are bugged for T42 and above.
I run all my models at T42 resolution these days. You could try a different topography map to see if it makes any difference, because I can't see what about that script might be causing trouble, other than perhaps needing physicsfilters (which I pretty much always run with these days as well).
DeleteBased on some quick looking around, exit status 136 may refer to a memory shortage; are you particularly short on RAM?
I have 10GB of RAM free when the crash occurs, so I doubt it. Physicsfilters seem to have no bearing on the crash either.
DeleteAfter some more testing, I have found that the topographic complexity of the map seems to effect how it crashes: a map with over 100 different elevations crashes nearly immediately, a map with only 20 different elevations takes a few minutes to crash, and a map with 2 different elevations doesn't seem to crash at all.
An addendum: it's not as simple as the number of different elevations. The map I tried with 2 different elevations was an image of a white circle on a black background. I just tried to use the debug land mask image of the map I was using in the rest of the tests as an input image, and that crashed. This seems to indicate that the shape of the land (or the water) itself is contributing to the crash, rather than the different elevations.
DeleteI've used anywhere between 4 and 256 levels of elevation. I have heard that steep changes in topography could cause issues (the model does attempt to avoid this by smoothing things a little internally, and physicsfilters or lower timesteps should also help as well but evidently not totally reliably. I tend to go with 30-minute timesteps on T42 runs by default), though that seems a little counterintuitive to your results. If you liked, you could take the map from the start of this post that I've been using reliably (https://worldbuildingpasta.blogspot.com/2022/05/climate-explorations-temperature.html ; min elevation 0, max elevation 6300 m, seas at 0 greyscale) and see if that works.
DeleteThat image does work for me, oddly enough. Could you try using this image (https://i.imgur.com/LQIP2pM.png) and seeing if it crashes for you? If it passes year 0, it should be fine.
DeleteNever mind, it doesn't work. The same crash happens after year 1.
DeleteRecently, I installed Leap to be sure that WSL2 wasn't behind the issues I've been having. Fortunately, the terminal here produces a much better stacktrace. As it turns out, the crash was being caused by a SIGFPE on an ozone calculation. So setting ozone=False should have fixed it, right? NOPE. When I ran it after turning ozone off, it crashed on the same ozone calculation again anyway (???) and simultaneously segfaulted (?????????????).
DeleteI've also had unrelated crashes from a coordinate related calculation (when ncpus isn't a power of 2), a wet soil albedo calculation (I have no idea what causes this; it doesn't happen all the time, and it is persistent when it starts happening. Fortunately, this one *can* be fixed by turning off wet soil albedo.), and a surface air humidity calculation (in a subsequent run after turning ozone off, this one only has happened once so far), all SIGFPE, and none of them prevented by physicsfilters.
I am using a Ryzen 5 3600 if that helps anyone identify the issue.
I doubt the fault arises from any of these modules specifically, there's just some fundamental instability here. Significantly reducing the timestep may help (I sometimes go down to as little as 10 min), but otherwise it's possible something about the compiler and your hardware is just not getting along, and that's well beyond my knowledge base. You might see if the dev knows anything via the github.
DeleteI found the issue, there is a bug in the ExoPlaSim-InCon-master script, it wont add the physics filter even if u check select it.
DeleteDo you know of any way to fix this error in the master script? If so (or if you have any leads on potential ways to fix it), please share them with us :D
Delete~ Nashed
Oops. Completely overlooked the fact that I could just open up my script and edit it myself. My bad.
DeleteHowever, even though I have set the physicsfilter option to 'gp|exp|sp' as is recommended, my simulation is still crashing in this way. :(
Update: recreated the SRA files for T21 and ran at that resolution and there is no crash. Is there anything about the higher resolution that could make it crash?
ReplyDeleteDisregard this. I had input the path to the SRA files wrong for this one (and the program still ran somehow? got stuck on year 0 though).
DeleteIs there any way to set the initial temperature of the planet? I notice that a lot of the time simulated is just bringing the planet up to temperature, so starting near that temperature would cut down a lot on simulation time. A script to create a restart file would probably work best (and would also allow for furthur cuts to simulation time by approximating other quantities as well) would be ideal, but I have no idea how restart files are formatted.
ReplyDeleteSo far as I'm aware ExoPlaSim doesn't have any particular way to allow that. Altering or creating restart files would be useful for a number of reasons, but as I understand it the data exists there in a somewhat bizarre format that doesn't correspond neatly to map coordinates. It has been suggested that the postprocessor could be used as an interface to allow something like this, but I haven't even begun to investigate that as of yet.
DeleteI'm not sure that it would be desirable to do this anyway. The model already underrepresents glacial growth, and would do so more if started warm; it might even take longer for the climate to equilibriate from a "warm start" as glaciers slowly form at the poles rather than getting a bit of an initial boost (presuming we're aiming for Earthlike climates with some amount of glacial cover). Even if it didn't, it probably wouldn't save much time; the models usually take something like 50-100 years to fully equilibriate, but they're usually already most of the way there within 10.
How does your interpolation process in koppenpasta.py work? Does it interpolate each quantity individually, or does it interpolate a vector of all of the desired quantities? The latter would be preferred, as I'd bet that it stands a better chance of preserving any correlations in those quantities (even though I'd also bet it would also take longer, as not only would the interpolation function itself be more complicated, but you would also want to include quantities that aren't used for determining climate zones, such as wind speed/direction, so that the interpolation is more accurate).
ReplyDelete2-meter air temperature and precipitation and, depending on the configuration settings, surface temperature, sea ice cover, within-model surface elevation and my derived temperature lapse rate are all independently interpolated by spline interpolation. There may be some correlation between certain of these values (obviously between the temperature values, but so closely that considering them together would be almost redundant), but there'd be a lot of oddities to account for, like the way sea ice is zero in land cells for reasons totally independent of temperature, and the program outputs a few dozen parameters altogether, so it'd be hard to know what to pick and which might introduce more error through erroneous correlation. Even in the best case, it would probably be a lot of work for a small improvement in accuracy, especially compared to the inherent error of the model.
DeleteSomething interesting to note with Panoply: some variables (such as ps) will have all of their data points listed as 0.0, despite displaying a correct visualization. While the map alone is pretty useful, it's pretty annoying that you can't actually access the raw numbers. Is there any way to fix this?
ReplyDeleteIt's just the number format. You should be able to find dropdown menus here and there with options like "0f", "2G", etc, which correspond to different formats and numbers of significant figures.
DeleteHave you noticed a consistent average for the time it takes to finish a run-to-balance script? I’ve reached year 300+ on resolution T42 and I’m starting to run out of hard drive space…
ReplyDeleteIt's been pretty consistently 50 to 150 years for me, with the most dramatic changes generally happening within the first 20 years. Do you have any unusual parameters?
DeleteNothing crazy other than a low time stamp and greater vegetation growth. I also have the CO2 script running but it doesn’t seem to be caught in any sort of loop.
DeleteCoincidentally it finished today at year 397. Cheers.
DeleteThe CO2 script does take a bit longer than just running to balance, though usually not quite that long. If running up a new model, it may help to run it for something like 20 (rather than 5) years to start out with to give the model a bit of time to warm up from its initially cold state.
DeleteI've gotten exoplasim working great for me except that it seems to always immediately crash when I try to do a run with greater than 0.1 eccentricity. I've tried adjusting the timestep and physics filter to no avail.
ReplyDeleteI ran into this recently too, it's a hardcoded limitation left over from before PlaSim was intended only for Earth. The dev intends to look into it, but that's subject to their schedule.
DeleteRequired figuring out some stuff about fortran, a truly awful language, but I think I managed to get everything required to accurately simulate higher eccentricities working. Made a PR into the main repo or you can use my fork if you're interested. https://github.com/alphaparrot/ExoPlaSim/pull/2
DeleteI have the same problem. I want to run a simulation with eccentricity = 0.2 and it crashes instantly. I've tried downloading your radmod.f90 file and replacing it in the exoplasim installation folder, but running the simulation gives the same crash. Any help would be much apreciated.
DeleteI think I'm doing something wrong...maybe I didn't configure it correctly, because every time I run a simulation, it crashes. I keep getting the following errors:
ReplyDeleteNo module named 'exoplasim.pyfft'
[Errno 2] No such file or directory: 'MOST.00000.'
Error writing output to MOST.00000..npz; log written to postprocess.log
This happens on the sample script or anything else I've tried on this. I don't know if I should just delete everything and start over or what. I'm not a computer programmer, so if something is missing or not configured correctly, I have no clue. But if I could be pointed in the right direction, that will help.
"exoplasim.pyfft" errors are caused by an issue with configuration where it can't find certain numpy files, it seems to be an issue with latest numpy versions. The best way to fix it would be to completely uninstall exoplasim and numpy, then install exoplasim again and let the "pip install exoplasim" step handle installing numpy.
DeleteOk. I'll try that. Although, I ended up configuring the the plasim folder in the .local/.lib/(etc., etc.) and it all seemed to work. I ran my simulation, and all went well. It ended up running the entire 100 years...and then the files vanished. No trace anywhere whatsoever. [Insert Scream of Anguish here]
DeleteSorry, but would that mean deleting the entire folder "site-packages" folder or just "exoplasim"? And maybe I don't understand the configuration process, but I thought I had done it correctly by running "./configure.sh". Sorry for the questions; command line isn't my strong suit.
DeleteIf it's working then don't mess with it. when the model run completes it should move everything into an "out" folder in the same directory of the "run" folder. If that doesn't exist anywhere that might be a permissions issue.
DeleteSo, I guess I need to do a 'sudo nautilus'? (I'm on ubuntu.)
ReplyDeleteLast time, I think. I looked at the end of your script and the templates, and I believe I see that the problem is that the tool for making the script excludes the "save" line and probably a few others. I probably just need to copy one of the templates and use that instead. Wish me luck.
ReplyDeleteI got it to run, but for some reason, it seems to completely ignore the elevation map. Instead of zones of climates, I have belts running across the entire map. I've used the conversion tool in the script maker, and have tried using the standalone script as well. (I keep running into an index error in the script, so I have no Idea what I'm doing wrong there.)
ReplyDeleteThe only way I can get an Idea as to the climate zones (which may not be accurate due to the aforementioned problem) is to use a mask on both the koppen output and the sea output in GIMP. It looks nice, but somehow I don't know if it's "correct" I probably could fudge the areas a little, but at this point, I'm too committed to accuracy. Thanks!
I got it figured out. I just ended up saving my map through a different program and running exoplasim in the same directory I had all the maps in. The map parts of it worked out just fine, now I need to tweak my planet script a little bit...for me, it is trial and error; although it's more error than anything else!
DeleteEvery time I'm about to reply you work it out yourself, but cool that you got it working (maybe check the "lsm" data in the netcdf file, it shows you what the model is treating as land or sea). And yeah, it can take some tweaking, I've written here and in another post about using some python code to automate the process a bit.
DeleteYeah, funny that way. After tweaking the size of the planet just a smidge, I got it to run to balance (done in 75, not 100. Always a plus). The resulting climate maps I've made were not too off from my initial maps. Surprisingly, for an obliquity of 14.86 degrees, it had less desert areas than I was expecting, and a lot more humid/temperate climate zones. The ice encroached further into my continents than I expected too. Thank you for this wonderful tool!
DeleteIn case anyone else is *still* having issues with exoplasim.pyfft and reinstalling numpy doesn't work, for me the ./configure.sh on the ExoPlaSim directory calls the wrong f2py version (on the bottom of the script) so I hardcoded my version number on it as a quick fix.
ReplyDeleteCould you be more specific, please? How did you figure out what version it was calling, and what lines did you change to hardcode it? I feel like this might the problem I'm having.
DeleteIf you're already running linux and have python installed: I found some problems while trying to run this using Python 3.10. I'm using arch linux. Here's my journey:
ReplyDeleteIt started with an error: "RuntimeError: module compiled against API version 0x10 but this version of numpy is 0xe", which I tracked down to a version inconsistency with matplotlib. Installing an older version of matplotlib to my local user python library fixed that.
Then I was getting the error with exoplasim.pyfft not being found, and the suggestions above didn't fix it. I found another error way up near the top of the output: "ImportError: No module named distutils.msvccompiler". I could not resolve that error.
So, I decided to run this in a virtual environment which would let me run an earlier version of python. I ended up installing miniconda , although this should work with the full anaconda system. After setting up a conda environment which used python 3.6, the rest of the stuff works.
I wish I found this tool four weeks ago before I spent all sorts of time trying to develop my own climate simulation.
Anyway, I'm trying to get exoplasim to work with DEM files which I've been developing using QGIS, I'll try to keep you updated here if I can get it all to work.
While running a test on a sample map, I ran into an error: `../.local/bin/miniconda3/envs/exoplasim/bin/../lib/libstdc++.so.6: version ``GLIBCXX_3.4.30' not found (required by /usr/lib/libicuuc.so.72)`
DeleteI fixed it by doing the following, although I didn't like this method and I worry that it will get overwritten someday. This will only work if your system libstdc++ supports the version in the error message.
`mv .local/bin/miniconda3/envs/exoplasim/lib/libstdc++.so.6 .local/bin/miniconda3/envs/exoplasim/lib/libstdc++.so.6.old`
`ln -s /usr/lib/libstdc++.so.6 .local/bin/miniconda3/envs/exoplasim/lib/libstdc++.so.6`
I think there is a problem with the script output by the configuration tool.
DeleteMy initial test run ended with an error about some files being the same, but prior to that there were no errors. There was no output or crash directory, and the working directory was gone.
Looking at the script, which was generated by the tool using defaults, the values for workingdir, modelname and the argument to finalize were all the same value, "Earth". I changed these so they had different values, and the model ran fine and I found the output data where it should have been.
I just wanted to make a final update. I got what I needed out of this tool. This blog post was quite helpful. Here are a few additional things I got out of this:
DeleteApart from the problems I mentioned above, I also could not get ExoPlaSim to run it at T42 resolution. I tried three times, and each time the simulation ended on `SIGFPE: Floating-point exception`. As I'm using this for a fantasy map, I can get by with T21, although a higher resolution would be nice.
After running the koppen classification script with topographic file input, I found my first attempt had some weird results. There were huge ice caps in the tropics and a desert in the arctic instead of tundra. This may have been a combination of the low data resolution and my specific map, and for all I know a real planet that looked like mine would have those. I solved this by lowering the gravity value, which would have the effect of changing the adiabatic calculations.
Getting my heighmatp out of QGIS was easier than I expected, after I converted my TIF file to PNG and let the sra converting scripts work themselves. As I had some basins below sea level I had to generate two separate SRA files, one with the basins filled in, and used the ocean layer from one conversion and the land conversion from the other.
Getting the koppen data back into QGIS required two things: 1) a special color classification file to make it easier to turn the classifications into numbers and 2) a ".pgw" world file alongside the ".png" output.
I could also pull the NC files in myself to get data such as wind, although it required a little work to shift them into my project's coordinate system. Compiling them into an averages by month and season to get prevailing wind was a bit of work. I contemplated editing the koppen script to do this, as well as generate some monthly/seasonal average temperature and precipitation layers. However, I'm not strong in python, so I decided I didn't need them.
The one thing I missed from this process is the ocean current map, which I couldn't find among the variables in the NC output in panoply. I understand that ExoPlaSim uses a simplistic ocean circulation model, so I assume they didn't bother even attempting to generate them, as they would be meaningless. I ended up drawing this manually using your tips from your earlier article.
Floating point exception errors get thrown when something inside the model goes outside the expected range, usually somewhere gets too hot or issues can arise with very steep topography. T21 runs have some issue that generally causes them to come out ~10-15 C too cold, so that could be why it's not happening there. The climate you describe sounds like it might be caused by high obliquity, do you know what value you were using there? That might also explain the instability, high-obliquity planets get very hot near the poles in summer and are hotter than low obliquity planets on the whole.
DeletePulling data from the NC files is not too hard in python, with the netcdf and numpy packages it should be something like:
import numpy as np
from netCDF4 import Dataset as ds
data = ds('datafile.nc')
precip = data['pr'][:]
and the precipitation data is now in a numpy array, which could be printed out a variety of ways--I'm not sure which would be best for QGIS but numpy has pretty extensive documentation and tutorials. The koppenpasta script also works by making a numpy array of integer codes for the climate zones in each cell and then uses that to fill an image with appropriate rgb values (through a pretty inefficient bit of code I should really update), so it shouldn't be too hard to alter it to just export that array in some other format.
Ocean currents are not calculated, the ocean water in each cell is essentially just treated as a box that can hold heat and might freeze over.
Sorry for the late reply. The obliquity was 20, so not too much different from Earth.
DeleteI didn't mention it, but I'm using a modified elevation map of Venus from the magellan mission as the basis for my world. So, this isn't Earth-like land, there are some fairly high "plateaus" here and there, and quite a few large, areas below my chosen sea level. I'm not too worried about the weirdness of this, it's for a fantasy world, so I just needed something that looks real, and I'm satisfied with what I got.
I keep immediately getting the same error without the model even beginning to run, I'll copy-paste here. Think it may be related to the issue that another person had.
ReplyDeleteHere's the error message:
Command '['mpiexec -np 16 most_plasim_t42_l10_p16.x']' returned non-zero exit status 136.
mkdir: cannot create directory ‘/home/aendaryn/orthan_crashed’: File exists
Traceback (most recent call last):
File "/home/aendaryn/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 519, in runtobalance
subprocess.run([self._exec+self.executable],shell=True,check=True)
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['mpiexec -np 16 most_plasim_t42_l10_p16.x']' returned non-zero exit status 136.
It's also giving me something about a floating point exception? I am not very familiar with any of this
Hey, Nikolai! Guilherme here.
ReplyDeleteGreat tutorial as always, but I think I need some help.
I've run a T21 model and had no issues. However, if I try to run the exact same model (with correct resolution for the landmap and the topomap) it simply crashes. I've tried reducing the timestep, adding a physicsfilter parameter, changing the number of CPU cores in use (I have an i5 with 6 cores, but for some reason the program crashes if I try to use all of them. I've been using 4 so far), but nothing works. I'll post my error report:
--------------------------------------------------------------------------
[[59913,1],3]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:
Module: OpenFabrics (openib)
Host: localhost
Another transport will be used instead, although this may result in
lower performance.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 0.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[localhost.localdomain:14982] 3 more processes have sent help message help-mpi-btl-base.txt / btl:no-nics
[localhost.localdomain:14982] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
[ -e restart_dsnow ] && rm restart_dsnow
[ -e restart_xsnow ] && rm restart_xsnow
[ -e Abort_Message ] && exit 1
[ -e plasim_output ] && mv plasim_output MOST.00000
[ -e plasim_snapshot ] && mv plasim_snapshot MOST_SNAP.00000
[ -e plasim_diag ] && mv plasim_diag MOST_DIAG.00000
[ -e plasim_status ] && cp plasim_status plasim_restart
[ -e plasim_status ] && mv plasim_status MOST_REST.00000
[ -e restart_snow ] && mv restart_snow MOST_SNOW.00000
[ -e hurricane_indicators ] && mv hurricane_indicators MOST.00000.STORM
'152'
'152'
Error writing output to MOST.00000.nc; log written to postprocess.log
Going to stop here just in case......
Going to stop here just in case......
mkdir: cannot create directory ‘/home/guilherme/MahoriaT42/mahoria_crashed’: File exists
Traceback (most recent call last):
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1108, in postprocess
gravity=self.gravity,gascon=self.gascon,**kwargs)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 3646, in postprocess
physfilter=physfilter,logfile=logfile)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 1371, in dataset
gridlnps,lnpsmeta = _transformvar(lon[:],lat[:],rawdata[str(lnpscode)][:],ilibrary[str(lnpscode)][:],nlat,nlon,
KeyError: '152'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1108, in postprocess
gravity=self.gravity,gascon=self.gascon,**kwargs)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 3695, in postprocess
zonal=zonal, substellarlon=substellarlon, physfilter=physfilter,logfile=logfile)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 1371, in dataset
gridlnps,lnpsmeta = _transformvar(lon[:],lat[:],rawdata[str(lnpscode)][:],ilibrary[str(lnpscode)][:],nlat,nlon,
KeyError: '152'
(Continues on the comments)
During handling of the above exception, another exception occurred:
DeleteTraceback (most recent call last):
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 559, in runtobalance
log="burnout",crashifbroken=crashifbroken)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1128, in postprocess
if self.integritycheck("%s%s"%(inputfile,extension)):
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1165, in integritycheck
ioe = self.postprocess(ncfile[:-3],"example.nl",crashifbroken=False)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1138, in postprocess
raise RuntimeError("Going to stop here just in case......")
RuntimeError: Going to stop here just in case......
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "mahoriaT42.py", line 22, in
crashifbroken=True, clean=True)
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 638, in runtobalance
self._crash() #Bring in the cleaners
File "/home/guilherme/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1705, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/guilherme/MahoriaT42/mahoria_crashed/
--------------------------------------------------------------------------
I thought that could be due to issues with the postprocessor, but am not sure. Could such kind of thing happen in T42 or higher resolution, and not in T21?
I've likewise encountered this exact error, and it only appears to be occurring when anything higher than T21 is selected. T21 itself still works just fine across the many other configurations I've tried. My intuition is that it has something to do with pyburn.py, but I haven't been able to confirm this.
DeleteHello! I am trying to run this on my Windows 10 laptop, but I've ran into an issue, specifically at the part where we run the first .py script. I am using Notepad++ and the Konsole VM, as it is of more convenience for me atm. I created the program.py script and saved it. Unfortunately, inputting "python3 program.py" yields this: "python3: can't open file 'program.py': [Errno 2] No such file or directory". Same results are made when I try copying the dir file path from Notepad++.
ReplyDeleteI have asked other programmers about this. They indicated it's due to the program.py file being located on the WINDOWS side of the computer, not the LINUX side (in Layman's terms) (also unrelated but they were somewhat confused of the use with Notepad++). Am I missing something obvious? Thanks!
You would want to put the python script in your "home" folder inside the virtual machine; in a lot of ways the VM is treated as a separate computer from your main windows installation with it's own file system. I don't use the VM approach so I frankly don't know how moving stuff between them works, but this is hardly an exoplasim-specific issue so I imagine the information is online somewhere.
DeleteNotepad++ isn't normally used for python scripts (if you installed python in windows it comes packaged with its own editor) but these are very basic scripts that you could make in basically any text editor, it's just a bit easier to get the formatting right with notepad++
Hello ! I have been trying to run this on a Ubuntu virtual machine. When I try to run it, there always seems to be an error with the run command. I used your example with Earth-like parameters, and there is an exception with the model.run() command. I have tried playing around with the parameters inside it, but it always ends up the same way. Any idea as to why it does so and how I could sort this out ?
ReplyDeleteThe "run" command is the one that tells the whole model to run so there is a lot that can go wrong in there, I'd need to know more about the actual error (such as the exception message or when exactly it happens)
DeleteThanks for your answer,
DeleteI downloaded mpiexec, as it seemed it needed it. Now, I don't have any error message anymore, and it doesn't create a model_crashed folder. It creates a model_run folder, including a large number of files, but there is no .nc file, even though that is the output type that I specified.
Just in case, that's the error message that I got before downloading mpiexec:
TypeError: Model._run() got an unexpected keyword argument 'baseline'
the model needs to run for a good while to start producing output files
DeleteHas anyone tried running this on a cloud platform like pythonanywhere or AWS? My computer is not particularly powerful and even very low-res simulations take 24+ hours to stabilise, so I was wondering if anyone had experience of running the script remotely in order to benefit from increased processing power.
ReplyDeleteI do know of at least one person who got it running on AWS without any particular trouble, but I don't know much beyond that. I don't think pythonanywhere will work with the underlying fortran code the model itself ultimately runs on.
DeleteHello. Thanks for this wonderful blog I've discovered a few days ago. Great work really!
ReplyDeleteI have a little problem though : I have installed openSUSE Leap 15.4 on a virtual machine (skipping user and password step) to use exoplasim and I have followed your tutorial until the end of exoplasim install and the error code relative to PATH. So, I have modified the PATH as your tell and still get the same message error after saving the 'program' script as a .py file and putting it in /root/.local/bin .What am I doing wrong ?
Thanks for your answer.
Below are the last lines of openSUSE console:
-------------------------------------------------------------------------------------------------------------------------------------
Installing collected packages: numpy, scipy, python-dateutil, pillow, kiwisolver, cycler, matplotlib, cftime, netCDF4, exoplasim
WARNING: The scripts f2py, f2py3 and f2py3.6 are installed in '/root/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
WARNING: The scripts nc3tonc4, nc4tonc3 and ncinfo are installed in '/root/.local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed cftime-1.6.0 cycler-0.11.0 exoplasim-3.1.6 kiwisolver-1.3.1 matplotlib-3.3.4 netCDF4-1.6.2 numpy-1.19.5 pillow-8.4.0 python-dateutil-2.8.2 scipy-1.5.4
DESKTOP-VF9NK54:~ # PATH=$PATH:/root/.local/bin
DESKTOP-VF9NK54:~ # python3 program.py
python3: can't open file 'program.py': [Errno 2] No such file or directory
Edit of my message : I was trying to run the script from the wrong directory. Managed to start the test script you have provided but it crashes.
Delete------------------------------------------------------------------------------------------------------------------------------------------------------------
DESKTOP-VF9NK54:/home # python3 program.py
Checking for /root/.local/lib/python3.6/site-packages/exoplasim/plasim/run/most_plasim_t21_l5_p8.x....
Mean Molecular Weight set to 28.9703 g/mol
rm: cannot remove '/home/mymodel_testrun/plasim_restart': No such file or directory
--------------------------------------------------------------------------
mpiexec has detected an attempt to run as root.
Running at root is *strongly* discouraged as any mistake (e.g., in
defining TMPDIR) or bug can result in catastrophic damage to the OS
file system, leaving your system in an unusable state.
You can override this protection by adding the --allow-run-as-root
option to your cmd line. However, we reiterate our strong advice
against doing so - please do so at your own risk.
--------------------------------------------------------------------------
Command '['mpiexec -np 8 most_plasim_t21_l5_p8.x']' returned non-zero exit status 1.
Traceback (most recent call last):
File "/root/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 803, in _run
subprocess.run([self._exec+self.executable],shell=True,check=True)
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['mpiexec -np 8 most_plasim_t21_l5_p8.x']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "program.py", line 4, in
mymodel.run(years=10,crashifbroken=True)
File "/root/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 387, in run
self._run(**kwargs)
File "/root/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 885, in _run
self._crash() #Bring in the cleaners
File "/root/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1705, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/mymodel_crashed/
Honestly that's a new one, it seems like you've triggered some safety against running with too much permission. Did you do anything different in how you prepared for this or ran the model?
DeleteHello. Thanks for the answer. I've followed the tutorial and just changed the number of processors in the script ( 8 in spite of 4). I wonder what's going on. Maybe something related to the command mpiexec
Delete(CalledProcessError: Command '['mpiexec -np 8 most_plasim_t21_l5_p8.x']' returned non-zero exit status 1.)
I've tried to change the number of processors but got the same result.
Will check the code and surely re install the virtual machine then go again along the tutorial.
Thanks again.
Hello! I am having troubles with installing ExoPlaSim-InCon. I have no experience with python, and I can't find a way to install the app at all. If you could help me I'd really appreciate that!
ReplyDeleteI don't maintain or use eps-incon but I believe it's just a python script that you should run or execute once you have the right packages and then it should show a basic ui
DeleteHi! its been a very painful procress that has taken weeks, but managed to install it, im just flumoxed by this error: Checking for /home/felipe/.local/lib/python3.6/site-packages/exoplasim/plasim/run/most_plasim_t21_l5_p2.x....
ReplyDeleteMean Molecular Weight set to 28.9703 g/mol
rm: cannot remove '/home/felipe/test_files/Valgar/plasim_restart': No such file or directory
Writing configuration....
1
1167.0
6300.0
None
287.0000002469167
1.35
1
0
1.166
0
180.0
None
12.824
1.305
0.023
0.22
1507.0
1
None
1
0
0
None
8.0
8
15.0
None
None
None
None
None
None
None
50.0
None
0
None
None
None
ECHAM-3
0
None
0
0
None
0
0
None
1.0
50.0
None
None
0
None
45.0
None
None
toggle|0&start|320&end|576&interval|4
None
SRA/valgar_surf_0172.sra
SRA/valgar_surf_0129.sra
0
4
VITHRESH|0.145&GPITHRESH|0.37&VMXTHRESH|33.0&LAVTHRESH|1.2e-05&VRMTHRESH|0.577&MINSURFTEMP|298.15&MAXSURFTEMP|373.15&WINDTHRESH|33.0&SWINDTHRESH|20.5&SIZETHRESH|30&ENDTHRESH|16&MINSTORMLEN|256&MAXSTORMLEN|1024&NKTRIGGER|0&toggle|0
NSTPW@plasim_namelist|160~s
83217024.0
0&2.0&-1.0
0.0005
0.0
None
11520
0.0
0
1
1.0
0.5
1.0
2.0
0.0
0.0
1.0
Writing to /home/felipe/test_files/Valgar/Valgar.cfg....
STOP 999
STOP 999
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpiexec detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[30843,1],0]
Exit code: 231
--------------------------------------------------------------------------
Command '['mpiexec -np 2 most_plasim_t21_l5_p2.x']' returned non-zero exit status 231.
Traceback (most recent call last):
File "/home/felipe/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 803, in _run
subprocess.run([self._exec+self.executable],shell=True,check=True)
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['mpiexec -np 2 most_plasim_t21_l5_p2.x']' returned non-zero exit status 231.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "valgar.py", line 12, in
Valgar.run(years=100,crashifbroken=True,clean=True)
File "/home/felipe/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 387, in run
self._run(**kwargs)
File "/home/felipe/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 885, in _run
self._crash() #Bring in the cleaners
File "/home/felipe/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1705, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/felipe/test_files/Valgar_crashed/
I have no idea what to do, any tips please?
My best guess is that there's something about the setup that exoplasim can't quite handle; do you have high eccentricity? Exoplasim can't currently go over 0.1 eccentricity
DeleteWell eccentricity is 0.013 so that wasn't it, it was the long of periapsis. thank you!
DeleteEccentricity is capped at 0.1 in exoplasim? May I ask where in the docs or the code it says this? I'd like to look at it in detail, since I explicitly want to model high-eccentricity exoplanet climates.
DeleteIf this is something I can't get around, is there another similar program that you could recommend for such modeling? Thanks!
If you look at the push requests on the github there is a forked version which attempts to fix the eccentricity (I haven't had the chance to fully test it but it looks reasonable). If you install exoplasim and then replace the radmod.f90 file with the one from the fork before you run eps for the first time (because it configures when it first runs) it should work up to 0.7 eccentricity.
DeleteIf I've already run exoplasim for the first time using the eccentricity max=0.1, do I need to uninstall and reinstall it, then swap the radmod.f90 file? I'd prefer to avoid a reinstall if possible since it took me a (very) long time to get it to work on my mac, and honestly I'm not 100% sure how I finally did get it running.
DeleteYou would need to remove the exoplasim folder and then replace it (either with the exoplasim folder in that forked github repo or using pip install exoplasim), you wouldn't have to touch any of the dependencies.
DeleteHuh. I'm getting a similar error to Meihua: exoplasim.pyburn.postprocess() got multiple values for keyword argument 'variables'. Not sure why or how to resolve. It happens when I try to export data to any format other than the default .npy. I've sent an email to worldbuildingpasta@gmail.com with more info.
ReplyDeleteThere's a new update on the exoplasim github that might help, though I'm not sure if it's been updated to pip yet; otherwise removing any "cfgpostprocessor" lines might fix it if you don't mind sticking with 12 months.
DeleteDoes ExoPlaSim-InCon work on a mac? The README says it should, but when I start the python script I just get a blank grey box popup...no configuration interface at all. I'm trying to convert PNGs to .sra files.
ReplyDeleteI do not maintain or use eps-incon and I haven't touched a mac in ages so I don't know much about it. If you can't get it working, the image2sra script on the koppenpasta repository still works fine, you'd just have to make the model script yourself (based on one of the templates above).
DeleteHi! I'm having trouble with recovering a model object file if the save function doesn't get executed. I have a model that ran fully to balance, but somewhere between cleaning the folder and saving the model after that, it stopped working. It didn't fully crash, no crash folder was created, but it just stopped working. Is there a way to rebuild a model object with the full model history? Is this tied to a restart file? I really can't find any resources on how to actually use the restart files correctly. Thanks!
ReplyDeleteI think the save/load process requires the working directory to be largely untouched and I've honestly stopped using it. Using a restart file is as simple as putting its filepath in for the restartfile parameter of a model. If you still have all the .nc outputs for every where you can also add an inityear parameter to the model setup line (the first one where you define the model, not the configuration line where you'd put restartfile) and set it to the appropriate year following your last output year and it should continue from there rather than overwriting your existing outputs, and I think this might let it build a history? I know it works for runtobalance at least.
DeleteYep--that worked fine. I tossed in the restart file line, changed the inityear, and ran it for 1 year and it rebuilt a full model object file that I could save from there. Perfect, thanks!
DeleteHey! I have an issue with Alex's tool. It exports .sra files just fine, but the script just doen't appear, and it gives me this error:
ReplyDeleteInputs gathered...
Beginning Image -> SRA Conversion...
Width ratio: 25.0
Height ratio: 25.0
All ratios are good!
Conversion successful!
Formatting...
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib64/python3.6/tkinter/init.py", line 1705, in call
return self.func(*args)
File "EPS-IC.py", line 530, in save_file
snapshotstext = ',snapshots='+param[85]
TypeError: must be str, not int
Any way to fix this? I'm using openSUSE Leap 15.4 virtual machine. Thanks!
I had the same problem. Going into the script and changing "snapshotstext = ',snapshots='+param[85]" to "snapshotstext = ',snapshots='+str(param[85])" (line 530 in my script) fixed it for me
DeleteDo you know if there's a way to troubleshoot the arguments of a script? I have a suspicion that some of the arguments I'm specifying are somehow getting changed to something else in the running model. So I'd like to do something like get the running model to periodically output the list of arguments its using (flux, rotationperiod, obbliquity, etc). Can I do that?
ReplyDeleteNot that I'm aware of, but looking at the outputs might help; czen in particularly is good for checking if motion relative to the sun is right. I know that without fixedorbit=true it may default to Earth's orbital parameters but otherwise I haven't seen an issue like this.
DeleteYou can just run with default settings for 1 year and look at the output, the czen values shouldn't really change between years.
DeleteSince this is cosine, is this correct: czen = 1 would mean the sun is directly overhead, and czen = 0 would be the sun at the horizon?
DeleteAlso...the data structure of the output data (assuming times=12) is 12:32:64 for the lowest resolution. Presuming a basic-earth model is used as the template, and nothing is changed except rotation rate from model to model, is part 1 of 12 in the first dimension always representational of January? Or does varying rotation rate change which month part 1/12 represents? I ask b/c when I change rotation rate of a model (and nothing else) the seasons totally shift in the data structure. Northern winter may shift from month 1/12 to month 6/12 for example. I can confirm this from numerous values: czen, ts, rss, etc. This is happening with my old install, and a fresh install I did via pip today.
DeleteYou're right for czen, but it's averaged over the day (unless you look at the snapshots).
DeleteThe first output is not necessarily january (in the sense of being northern hemisphere midwinter), it can be altered by the lonvernaleq (or something like that) parameter. I don't know why rotation rate would affect it, I have recently been running a number of models at different rotation rates (ranging from 1/8 to 10 earth days so far) and they all show the same czen for the start of the year.
Are you using a recent install? As mentioned I just did a fresh install today and the problem persists. Something is very wrong it seems, and I can't figure out what, or even how it's possible. Changing rotation rate seems to alter aspects of the orbit calculation and (perhaps) even obliquity. It's very hard to tell because there aren't any output that explicitly state those things when the model is running, so I'm inferring all this from the variable outputs. Also, I can't set rotation to any amount below 0.50 as the model crashes. Even 0.499 rotation crashes.
DeleteAlso, for a fast rotator (hundreds of rotations per orbit) in a non-eccentric orbit, the czen should be the same value at all longitudes of a given latitude, right? Because I'm seeing slight deviations. Usually starting at the 3rd decimal place.
DeleteI'll update soon when the model's new orbital logic is ready and maybe run a couple tests then. Until then could you maybe send me a sample of the scripts you've been using?
DeleteAnd you're right that ideally czen should be continuous by latitude, but the model isn't a perfectly continuous sample; with something like a 30-40 minute timestep for 24-hour days the substellar point is skipping over grid cells between timesteps even at the coarsest resolution. If your day length doesn't neatly match up with the model's typical 5-day sampling period it uses for memory management that could also falsely bias the output.
Thank you! It's a huge relief to have someone knowledgeable take a look. I just sent off the email to worldbuildingpasta@gmail.com.
DeleteOh, I should mention I got rotations below 0.5 working. Reinstalling EPS seemed to do the trick—don't know why. So it's just the rotation-rate weirdness which is a problem.
DeleteNot sure exactly how I've gone wrong, but my final product doesn't seem to be correct (https://imgur.com/wMYKByq). I've been gut checking how things look as I go and then all seem to look ok:
Delete- Original topo map (https://imgur.com/zDHsKSd)
- Input greyscale topo map (https://imgur.com/4REoOyn)
- Debug land mask (https://imgur.com/WmSaSBB)
- Example air temperature (https://imgur.com/k9MWlq0)
- Average from 70 cycles (https://imgur.com/0xvPLGI)
I generated the original map through by amalgamating Songs of Eons continents, real life geography and general vibes, so I wonder if that that's the cause? I'm pretty stumped honestly.
Not sure exactly how I've gone wrong, but my final product doesn't seem to be correct (https://imgur.com/wMYKByq). I've been gut checking how things look as I go and then all seem to look ok:
ReplyDelete- Original topo map (https://imgur.com/zDHsKSd)
- Input greyscale topo map (https://imgur.com/4REoOyn)
- Debug land mask (https://imgur.com/WmSaSBB)
- Example air temperature (https://imgur.com/k9MWlq0)
- Average from 70 cycles (https://imgur.com/0xvPLGI)
I generated the original map through by amalgamating Songs of Eons continents, real life geography and general vibes, so I wonder if that that's the cause? I'm pretty stumped honestly. Any ideas?
I figured it out! I put the wrong resolution (twice as high as the correct number) and get bad .sra input files.
DeleteBeen getting these errors in between years recently. This is after a fresh install of openSuse and ExoPlaSim.
ReplyDeletecp: '/home/User/Pruned21/GUI.cfg' and '/home/User/Pruned21/GUI.cfg' are the same file
cp: '/home/User/Pruned21/Pruned21.cfg' and '/home/User/Pruned21/Pruned21.cfg' are the same file
When this happens it doesn't output a Model_Crashed folder or leave behind any folder, for that matter. Any ideas?
It seems the issue is tied to the scripts put out by EPS-IC. For some reason it gives the same name to the work directory and the output folder and then when ExoPlaSim attempted to create the latter it couldn't.
DeleteI'm not sure if this is due to a change in EPS-IC or if it's a permissions thing, as I haven't had this problem in the past. Regardless, the fix is simple. All you have to do is manually change the names of directory and output in the Python script.
Hello! I came across this tool after following Artifexian's recommendation and checking out your website. I've never used Linux before so it's all fairly new to me, but I've run into an error at the end of the "installing exoplasim" step which I'm unsure of how to fix. The last bit of output is as such:
ReplyDeleteTraceback (most recent call last):
File "program.py", line 4, in
mymodel.run(years=10,crashifbroken=True)
File "/home/dontpanic/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 387, in run
self._run(**kwargs)
File "/home/dontpanic/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 885, in _run
self._crash() #Bring in the cleaners
File "/home/dontpanic/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1705, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/dontpanic/mymodel_crashed/
I've seen that some other users have had a similar issue, and wasn't sure if a fix has been found?
At a glance this doesn't look like a specific issue, Exoplasim is just a very crashy model. If it happens consistently, reducing the timestep may help, and you may also want to check the outputs prior to the crash to see if it's getting too hot.
DeleteDid you also happen to come across this?
Deletemake: *** No rule to make target '.f90', needed by '.o'. Stop.
From what I have heard from an experienced OpenSUSE Leap user, this is likely what the cause is, since it's a bad makefile command. Unsure exactly how to mitigate it though, may have to speak with them further.
Hi!
ReplyDeleteYesterday I wanted to do the openSUSE start-up but I ran into an issue, so I you don't mind if I do a quick rundown of the steps of the process I'm not sure I did correctly. I've never installed a Linux OS and I can't really find troubleshooting forums where I understand what the answers mean.
1) I downloaded the updated offline image for Intel
2) The Network Settings steps asks you to configure a wifi network, is this necessary? I skipped this step the first time I tried because I didn't really understand what I had to do.
3) I got stuck when I came to the Installation Settings, where under Software I got the error message 'Cannot solve dependencies automatically. Manual intervention is required.' When I clicked further, I got the message that Firewalld was not installed. It only gave me two options that seemed to be slightly different ways to start the systems while ignoring the Firewalld, but after each option I just got the 'Cannot sovle dependencies' message again.
Do you know what I could do in this situation?
Thanks in advance
Is anyone else having extremely slow throughput for T42? I would have throught it would be perhaps 4x as slow as T21, I was getting about 5-7 minutes per year cycle, but with T42 after Year 0, it's been running for the last 40 minutes...
ReplyDeleteThat's not unusual; my full T42 runs often take several days
DeleteAh, okay thanks. I'll stay on it then! There's another isue that seems to have come out of nowhere T_T
DeleteDo you happen to know a lot about pyburn.py and how it works?
I've had the below issue now, that seems to stem from pyburn attempting to log some variable called 'variable' that under certain circumstances doens't get assigned.
An error was encountered, likely with the postprocessor. ExoPlaSim was unable to investigate further due to a recursion trap.
An error was encountered, likely with the postprocessor. ExoPlaSim was unable to investigate further due to a recursion trap.
Traceback (most recent call last):
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1109, in postprocess
gravity=self.gravity,gascon=self.gascon,**kwargs)
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 3687, in postprocess
physfilter=physfilter,logfile=logfile)
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 2143, in dataset
_log(logfile,"Collected variable: %8s\t.... %3d timestamps"%(meta[0],variable.shape[0]))
UnboundLocalError: local variable 'variable' referenced before assignment
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 561, in runtobalance
log="snapout",crashifbroken=crashifbroken)
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1136, in postprocess
raise RuntimeError("An error was encountered, likely with the postprocessor. ExoPlaSim was unable to investigate further due to a recursion trap.")
RuntimeError: An error was encountered, likely with the postprocessor. ExoPlaSim was unable to investigate further due to a recursion trap.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "../elion.py", line 39, in
model.runtobalance(baseline=10, maxyears=300, minyears=20, timelimit=480, clean=False)
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 638, in runtobalance
self._crash() #Bring in the cleaners
File "/home/aminata/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1706, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/aminata/worldbuilding/ellion_6.1/ellion_6.1_T42_crashed/
I attempted to handle the unbound variable exception with a try except block, which did allow the run to continue without issue, but suspiciously quickly. It turns out data was being lost from year to year, and exoplasim just wasn't working. In trying to understand the code, I can see that there's a main loop that iterates over a load of climate varibles, which are processed is some way and loaded into some data stucture at the end.
The above error, (I think) appears to be the result of specific and if-ifelse block (lines 2131-2141), that check for variables called 'thetahcode' and 'thetafcode' if either of them are equal to some key value, it performs a tranformation on the variable data. I think a set of variables (I think - nu, lambda, zdec and rdist) have 'key' values that return trigger either conditions in the above if-else block, and since there's no else no tranformation happens, and nothing is assinged.
I don't know what the default, or intended behaviour should be so I don't know what exactly needs to be fixed, but I'm pretty sure this is what needs to be fixed. Wow okay, bed time.
Oh right, that's me above and also I'm using VM, which also might ahve something to do with why this is broken
DeletePyburn handles saving data to the output files, I think this is a bug that has recently been fixed on the github of exoplasim but hasn't been pushed to the current version through pip just yet. You can try downloading the version there and replacing your exoplasim folder, or if you have a "cfgpostprocessor" line, removing that might also fix it.
DeleteThanks so much for getting back to me so quickly, you're such a hero! I'm a little bit confused about the fix you suggested. I downloaded the zip file from the github page, and stuck the exoplasim folder into my "/home/{user}/.local/lib/python3.6/site-packages/exoplasim" directory. I ran the model and just failed right away, am I doing somethig wrong?
DeleteRE commenting out "cfgpostprocessor," wouldn't this change the outputs to not being in monthly timesteps anymore?
Did you replace the exoplasim folder or put the other one in it? It'd probably be safest to delete it entirely and replace it, and if that doesn't work then just delete it again, get the version from pip, and try without cfgpostprocessor; the model will output to 12 months by default, it's only necessary if you want something other than that
DeleteHello,
ReplyDeleteAfter trying to install on both a VM and a partition, I encounter the same problem: I manage to run the first script without any problem, but as soon as I try to add the postprocessor line, I get the following error:
[ -e restart_dsnow ] && rm restart_dsnow
[ -e restart_xsnow ] && rm restart_xsnow
[ -e Abort_Message ] && exit 1
[ -e plasim_output ] && mv plasim_output MOST.00000
[ -e plasim_snapshot ] && mv plasim_snapshot MOST_SNAP.00000
[ -e plasim_diag ] && mv plasim_diag MOST_DIAG.00000
[ -e plasim_status ] && cp plasim_status plasim_restart
[ -e plasim_status ] && mv plasim_status MOST_REST.00000
[ -e restart_snow ] && mv restart_snow MOST_SNOW.00000
[ -e hurricane_indicators ] && mv hurricane_indicators MOST.00000.STORM
[Errno 2] No such file or directory: 'MOST.00000'
Error writing output to MOST.00000.npz; log written to postprocess.log
Going to stop here just in case......
Traceback (most recent call last):
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1118, in postprocess
gravity=self.gravity,gascon=self.gascon,**newkwargs)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 3737, in postprocess
zonal=zonal, substellarlon=substellarlon, physfilter=physfilter,logfile=logfile)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 1390, in dataset
rawdata = readfile(filename)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 560, in readfile
with open(filename,"rb") as fb:
FileNotFoundError: [Errno 2] No such file or directory: 'MOST.00000'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 598, in runtobalance
check=self.integritycheck(dataname+"%s"%self.extension)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1175, in integritycheck
ioe = self.postprocess(ncfile[:-3],"example.nl",crashifbroken=False)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1148, in postprocess
raise RuntimeError("Going to stop here just in case......")
RuntimeError: Going to stop here just in case......
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "script.py", line 15, in
world.runtobalance(baseline=10, maxyears=100, minyears=10, timelimit=480, clean=True)
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 642, in runtobalance
self._crash() #Bring in the cleaners
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1731, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/ggarge/world_crashed/
I have a feeling that the line :
FileNotFoundError: [Errno 2] No such file or directory: 'MOST.00000'
explains the error but I'm unable to both check and correct it. Could you help me? Thanks!
If you have a "cfgpostprocessor" line, try deleting that or adding a parameter for extension='.nc'
DeleteThanks for your response ! Indeed, without the cdfpostprocessor, it worked. I have added the option extension=".nc" and now I have the output needed. Once again, thank you for your help and for this great tutorial!
DeleteHello !
DeleteI apologize again for the inconvenience, but I'm still having a problem :
Since applying the patch, I've been able to run simulations with the "T21" option, but as soon as I try to increase it to "T42", I get the error "SIGFPE: Floating-point exception" for all the maps I've tried. For the moment, I'm trying with topographic maps from "songs of the eons", so this may be the cause of the problem... Furthermore, I've obtained some surprising results (no glacier formation on a continent at the North Pole surrounded by sea ice and with parameters similar to the Earth except for a partial pressure of CO2 of 270.10^-6 bar).
Are you using different topography files? They have to be made separately for each resolution. You also can't use a restart from one resolution to continue at another, don't know if you meant that.
DeleteGlaciers are tricky; part of the issue is that exoplasim doesn't model the spread of glaciers and so will always tend to underestimate their spread, but glacier cover is also very sensitive to climate history; an identical Earth with no history of glacial cover given the same parameters as modern Earth would likely balance out to have less glacial cover than we do in reality, coming out of the depths of an ice age. I've found that starting off an exoplasim run with 1 meter of initial glacier cover does help encourage a result closer to modern Earth, but it will take longer to balance out and it can cause some planets to just snowball.
Each time I changed topography, I restarted the simulation completely from the beginning, no restarts.
DeleteI'm trying an approach with the topography from songs of eons with a high Gaussian blur, so far it seems to work.
In the end, applying gaussian blur to the topography didn't solve the problem... I get the following error every time (17th year):
Delete[MSI:3032 :0:3032] Caught signal 8 (Floating point exception: floating-point invalid operation)
==== backtrace (tid: 3032) ====
0 /usr/lib64/libucs.so.0(ucs_handle_error+0x10c) [0x7efddb6e035c]
1 /usr/lib64/libucs.so.0(+0x276dc) [0x7efddb6e06dc]
2 /usr/lib64/libucs.so.0(+0x2798a) [0x7efddb6e098a]
3 /lib64/libpthread.so.0(+0x168c0) [0x7efde686d8c0]
4 most_plasim_t42_l10_p8.x() [0x47e601]
5 most_plasim_t42_l10_p8.x() [0x48a3f0]
6 most_plasim_t42_l10_p8.x() [0x44a425]
7 most_plasim_t42_l10_p8.x() [0x450089]
8 most_plasim_t42_l10_p8.x() [0x4022c4]
9 /lib64/libc.so.6(__libc_start_main+0xef) [0x7efde649729d]
10 most_plasim_t42_l10_p8.x() [0x40231a]
=================================
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x7efde7246640 in ???
#1 0x7efde7245873 in ???
#2 0x7efde686d8bf in ???
#3 0x47e601 in ???
#4 0x48a3ef in ???
#5 0x44a424 in ???
#6 0x450088 in ???
#7 0x4022c3 in ???
#8 0x7efde649729c in ???
#9 0x402319 in _start
at ../sysdeps/x86_64/start.S:120
#10 0xffffffffffffffff in ???
--------------------------------------------------------------------------
mpiexec noticed that process rank 6 with PID 3032 on node MSI exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------
Command '['mpiexec -np 8 most_plasim_t42_l10_p8.x']' returned non-zero exit status 136.
Traceback (most recent call last):
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 523, in runtobalance
subprocess.run([self._exec+self.executable],shell=True,check=True)
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['mpiexec -np 8 most_plasim_t42_l10_p8.x']' returned non-zero exit status 136.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "script.py", line 65, in
clean=True #removes unnecessary files between years
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 642, in runtobalance
self._crash() #Bring in the cleaners
File "/home/ggarge/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1731, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/ggarge/workdir/model_crashed/
I'm sorry, I didn't really understand your answer either. In fact, I started by trying the T21 resolution. Then I wanted to try the T42 resolution, which was supposed to be more stable and, above all, more accurate. So I started a new simulation from scratch. The problem I'm facing is that each time I try a new topography (corresponding to a new simulation from scratch), I get the same error, even after I tried yesterday to run a simulation without SRA files. I'm running some tests right now in T21 to see if this is related to the resolution, although I find it surprising.
DeleteHello !
DeleteFinally, I've found a solution to my problem: Changing the timestep from 45 to 30 minutes (so the source of the problem hasn't been identified, but at least I've got a fix).
(Let me say at the beginning that I am not good at English. Sorry if I have wrong English.)
ReplyDeleteI have been trying my own world climate simulation for about 6 months since I found your article.
After several errors about the same postprocessor as others, I tried replacing exoplasim with the latest version on github but it did not work.
I recently found that adding extension='.nc' to the postprocessor line eliminates the previous error. However, there is a new error. Here is the error
~~
cannot reshape array of size 2654208 into shape (64,5,64,128)
cannot reshape array of size 2654208 into shape (64,5,64,128)
Error writing output to MOST_SNAP.00000.nc; log written to postprocess.log
Going to stop here just in case......
Going to stop here just in case......
mkdir: cannot create directory ‘/home/kaeru/eikyu_crashed’: File exists
Traceback (most recent call last):
File "/home/kaeru/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1210, in postprocess
gravity=self.gravity,gascon=self.gascon,**newkwargs)
File "/home/kaeru/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 3688, in postprocess
physfilter=physfilter,logfile=logfile)
File "/home/kaeru/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 1390, in dataset
rawdata = readfile(filename)
File "/home/kaeru/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 578, in readfile
data[key] = refactorvariable(variables[key],headers[key],nlev=nlevs)
File "/home/kaeru/.local/lib/python3.6/site-packages/exoplasim/pyburn.py", line 539, in refactorvariable
newvar = np.reshape(variable,(ntimes,nlevs,dim2,dim1))
File "<__array_function__ internals>", line 6, in reshape
File "/home/kaeru/.local/lib/python3.6/site-packages/numpy/core/fromnumeric.py", line 299, in reshape
return _wrapfunc(a, 'reshape', newshape, order=order)
File "/home/kaeru/.local/lib/python3.6/site-packages/numpy/core/fromnumeric.py", line 58, in _wrapfunc
return bound(*args, **kwds)
ValueError: cannot reshape array of size 2654208 into shape (64,5,64,128)
~~
The array the program is trying to shape seems to be 4 dimensional, I don't know about the first "64", but it seems that the other 3 probably correspond to the layers and the height and width of the map.
Since I used to use EPS-IC and ignore the generated .py files and only use .sra, I thought there might be some discrepancy between the .sra and the existing .py file, so I tried to generate a .sra with the existing .py file, matching the EPS-IC settings as closely as possible.
However, nothing changed and I am still getting the error above. The "2654208" part of the error is also unchanged. (I tried deleting the postprocessor line, but that did not change the result.)
Also, the error still occurs even after deleting the folder generated by the previous simulation.
Does anyone have any information on this error?
I've seen this before and never quite worked out what caused it but it occurs to me now that it could be a mismatch between the snapshot time and year length. If you have a "snapshots" parameter, delete that, and if that doesn't do it, could you tell me your values for year and timestep?
Delete(Sorry. I thought I replied as soon as I got your reply, but somehow my reply seems to have disappeared, so I'm sending it again.)
DeleteThank you for your reply.
I checked and there is no "snapshots" parameter in my model. (I am coding based on the template program in this article)
The timestep in my model is 30 minutes, year is 540 days, rotationperiod is 1, so I set runstep to 25920.
Also, here is all of my code
~~
import exoplasim as exo
eikyu = exo.Model(workdir='eikyu_run', modelname='eikyu', outputtype='.nc',
resolution='T42', layers=5, ncpus=16, precision=8, crashtolerant=True)
eikyu.configure(timestep=30, runsteps=25920, otherargs={'NSTPW@plasim_namelist':'240'},
physicsfilter='gp|exp|sp',
flux=1366, startemp=6200,
year=540, eccentricity=0.016715, fixedorbit=True,
rotationperiod=1, obliquity=23.2, lonvernaleq=102.7,
synchronous=False, substellarlon=180, desync=0, tlcontrast=0,
gravity=10.11514, radius=1.0304,
landmap="./SRA/eikyu_surf_0172.sra", topomap="./SRA/eikyu_surf_0129.sra",
pN2=0.7809, pO2=0.2095, pAr=0.0093, pCO2=300e-6, ozone=True,
pH2=0, pHe=0, pNe=0, pKr=0, pH2O=0,
wetsoil=True, vegetation=2, vegaccel=1, initgrowth=0.5,
glaciers={'toggle': True, 'mindepth': 2, 'initialh': -1}
)
eikyu.cfgpostprocessor(times=18, extension='.nc')
eikyu.exportcfg()
eikyu.runtobalance(baseline=10, maxyears=100, minyears=10, timelimit=480, clean=True)
eikyu.finalize('eikyu_out', allyears=True, clean=True, keeprestarts=True)
eikyu.save()
Hello,
ReplyDeleteI'm coming back to you about adding glaciers. You had suggested adding glaciers over the entire surface with a thickness of 1m. At this stage, my glacier is melting but it seems to be remaining on the sides. I'd like to know if you're experiencing the same phenomenon. Thank you in advance!
Not sure what you mean by the "sides"; if you mean the poles, then yes that will happen, and it takes a good deal longer for the climate to balance out if you do this; if you mean the left and right edges of the map, then no I haven't seen that, perhaps check if you have inadvertently put tidal-locking on?
DeleteSo, I can run all the scripts and programmes no problem, but I seem to be running into an issue nonetheless.
ReplyDeleteExoPlaSim seems to be unable to simulate the surface's temperature. When I open the results of a simulation in Panoply in the "Air Temperature (2m)" menu (for example), the ocean temperatures are modeled nicely and change properly with the seasons, but the surface temperature is largely static.
It seems to hover between 0-4°c on land, even if the temperature difference between ocean and land exceeds 20°c (or more!)
What I've tried so far...
- T21/T42 resolutions
- Earth heightmap instead of my own (at T21/10 years to test, temperature range in this simulation is ~1°c for highest to lowest)
- Reprocessing my own heightmap
- Both heightmap to SRA tools
- Physics Filter on/off
- Longer run times (highest I've tested is 70 years)
- The script that auto-adjusts CO2 values (crashes after a couple of years)
I'm kind of at a loss here, any ideas? I will be wiping the whole system and reinstalling from scratch just in case, I'll report back when I have more data. Thanks in advance!
Can confirm that a fresh, full re-install does not change a thing.
DeleteNot the first to report this actually; try uninstalling and deleting the folder (to remove any files made on configuration) and then running "pip install exoplasim[netCDF4]==3.2.4" to get the previous version.
DeleteI'd like to report that it works perfectly now, cheers!
DeleteI had to re-do my laptop. Trying to get ExoPlaSim to run in Mint 21.2. I had figured out how to make it work back in October (mine are the comments from 22/10/22), but I cannot for the life of me remember what I did to make it work. I had configured something in a folder, but nothing jogs my memory. I have deleted and reinstalled a number of times, and every time I test one of my programs for EPS, it throws a lot of errors at me, changes the file contents in the appropriate .local directory. Then I go back and start all over again. I cannot get the script maker to work, either. It keeps saying there are things missing like, No module named 'matplotlib'. My current python version is 3.10.6. What do I need to do/or can I do?
ReplyDeleteAll my previous statements regarding my programmer skills stand.
Update on current situation, plus maybe a few additional questions...I was able to get the script maker working, so that's good.
DeleteHowever, when configuring the program, (whether I try running a script or running "configure.sh" file,) I keep seeing (in red text) this :"WARN: Could not locate executable armflang"
How significant is this? I couldn't really find anything I could understand in a search. As far as I can tell, I have all the dependencies. Is it the python version I'm using? (3.10.6)? Thanks.
I took a suggestion of installing exoplasim 3.2.4 in a previous comment. Seems to be working just fine now.
DeleteI am having some odd problems that does not seemed to be addressed by anyone else in the comments or have any mention in the guide. I have installed and got exoplasim to work on Opensuse leap 15.4 on wsl and on a separate computer with Centos 9. The issue affecting both of those installations is that for some reason running a simulation at T21 resolution results in a crash, but running at anything higher works fine. However, those higher resolution runs are unusable as all arrays relating to vegetation except vegf (forest cover) are missing. This results in the the eps_avg script unable to convert the precipitation and when used with the koppenpasta script it will always create tundra planets with equatorial deserts. I have no idea why this is happening, but when using exoplasim on a separate computer with Opensuse leap 15.5 installed, the program works just as intended. All necessary packages as stated in the guide were installed on the VM and Centos 9 and no matter how I change the vegetation parameters with Alex's tool, the only vegetation array is vegf.
ReplyDeleteThat's a new one to me honestly, you may want to look over the scripts the setup tool makes and compare them against the exoplasim documentation (it could be an issue with the postprocessor setup?)
DeleteI've made some tiny progress in solving instant crashes for T21 resolution runs. Instead of outputting as .nc, I set it to output as .hdf5. The program.py script supplied in the guide doesn't seem to work in any other version outside of Opensuse 15.3, as when running in the VM, Centos 9, and Opensuse 15.5 it crashes. When using a basic script that was found on the official python page which is similar to the script in the guide, exoplasim works (the script will be at the bottom of this comment, the main differences are the presence of exportcfg and absence of precision variable).
DeleteHowever vegf still remains the only vegetation array present. One thing that might be important to add is that in addition to all the other vegetation arrays being missing, the long names of the arrays are missing as well, with the short codename being in the spot where the long name should be.
Another thing that might help is to run VM Opensuse through the Windows Subsystem for Linux app that can also be downloaded on the Microsoft store instead of the actual Opensuse app. I think you will still need to launch the actual app once for it to install.
My hunch going forward is that the configuration scripts produced by the tool are for some reason "incorrect" for VM and Centos 9 exoplasim installations.
The script:
import exoplasim as exo
mymodel = exo.Model(workdir="mymodel_testrun",modelname="mymodel",resolution="T21",layers=10,ncpus=8)
mymodel.configure()
mymodel.exportcfg()
mymodel.run(years=100,crashifbroken=True)
mymodel.finalize("mymodel_output")
I am encountering a similar issue with vegetation, at both T21 and T42. I consistently get tundra worlds with equatorial deserts as described above. I also am missing vegetation arrays other than vegf - and when I open vegf in Panoply, it appears to have no data. I am running OpenSuse 15.5 on a Windows partition.
DeleteHere's my script, for reference:
import exoplasim as exo
arven = exo.Model(workdir="arven",modelname="arven",inityear=0,outputtype=".nc",ncpus=16,precision=8,resolution="T21",crashtolerant=True,layers=10)
arven.configure(startemp=5772.0,flux=1367.0,
year=360.0,eccentricity=0.016715,obliquity=23.441,lonvernaleq=102.7,fixedorbit=True,
rotationperiod=1.0,
gravity=9.80665,radius=1.0,
wetsoil=True,seaice=True,oceanzenith="ECHAM-3",
landmap="SRA/arven_surf_0172.sra",topomap="SRA/arven_surf_0129.sra",
drycore=False,ozone=False,
pH2=0.0,pHe=0.0,pN2=0.7809,pO2=0.2095,pAr=0.0093,pNe=0.0,pKr=0.0,pH2O=0.0,pCO2=0.0003,
glaciers={'toggle': True,'mindepth': 2.0,'initialh': -1.0},
timestep=45.0,runsteps=11520,otherargs={'NSTPW@plasim_namelist':'160'})
arven.exportcfg()
arven.runtobalance(threshold=0.0005,baseline=10,maxyears=100,minyears=10,crashifbroken=True,clean=True)
arven.finalize("arven",allyears=True,keeprestarts=True,clean=True)
The vegetation model needs to be specifically toggled on with vegetation=2. The tundra planets issue may actually be a bug with current version of exoplasim, to downgrade to the previous version uninstall it, delete the directory in site packages, and use pip install exoplasim[netCDF4]==3.2.4
DeleteAny updates in regards to the other climate simulation programs you listed?
ReplyDeleteSomeone made a Docker container for ROCKE3D but it still looks like it'd be a pain to get running, let alone trying to work out how to import new topography https://github.com/hannahwoodward/docker-rocke3d . I really wouldn't be holding my breath for anything preferable to exoplasim for home use in the near future
DeleteHi!
ReplyDeleteI've been tryïng to run this on Mac, but I ran into an "Exoplasim has begun producing garbage" issue with the test script (before the configuration step).
Here's what I typed into console and what I got out:
Upstairs-iMac:~ potato$ python3 exoplasimtest.py &
[3] 69836
Upstairs-iMac:~ potato$ mkdir: /Users/potato/mymodel_testrun/: File exists
Checking for /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/plasim/run/most_plasim_t21_l5_p4.x....
PRODUCING: -r4 -o most_plasim_t21_l5_p4.x
Writing resmod.f90.....
rm: plasim.x: No such file or directory
rm: ../bin/most_plasim_t21_l5_p4.x: No such file or directory
rm: ../run/most_plasim_t21_l5_p4.x: No such file or directory
cp: ../src/specs is a directory (not copied).
Writing makefile...
make: *** No rule to make target `.f90', needed by `.o'. Stop.
ld: warning: ignoring duplicate libraries: '-lgcc', '-lgcc_s.1.1'
ld: warning: ignoring duplicate libraries: '-lgcc', '-lgcc_s.1.1'
cp: plasim.x: No such file or directory
cp: ../bin/most_plasim_t21_l5_p4.x: No such file or directory
cp: /Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/plasim/run/most_plasim_t21_l5_p4.x: No such file or directory
Mean Molecular Weight set to 28.9703 g/mol
rm: /Users/potato/mymodel_testrun/plasim_restart: No such file or directory
sh: mpiexec: command not found
runtime crash
mkdir: /Users/potato/mymodel_crashed: File exists
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/__init__.py", line 950, in _run
raise Exception("runtime crash")
Exception: runtime crash
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/potato/exoplasimtest.py", line 4, in
mymodel.run(years=10,crashifbroken=True)
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/__init__.py", line 507, in run
self._run(**kwargs)
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/__init__.py", line 1041, in _run
self._crash() #Bring in the cleaners
^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/exoplasim/__init__.py", line 1883, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /Users/potato/mymodel_crashed/
Is this a problem with the computer running specifically the test script (in this case would tryïng it with my actual configurations I wanna put in work?), or is this a problem I'd need to fix in general (that would apply to all scripts/configurations I attempt to run through Exoplasim). If this is a problem I need to fix in general, how I should I go about doïng so?
Sorry if this is super obviöus, I'm just not very good with computers.
~ Nashed
Hi! Nashed again.
DeleteI found a reddit post on the r/openSUSE subreddit (linked at bottom of comment) creäted by somebody with the same issue. I installed openMPI 5.0 from the tar.gz package on the openMPI website and now this error message is gone (there's a new set of error messages and crashes, but they seem to be unrelated).
Reddit link: reddit.com/r/openSUSE/comments/13z1f3p/opensuse_leap_154_running_into_problems_with/
Thanks for the great tutoriäl! :D
Hi, great article!
ReplyDeleteI've followed along on a Linux partition until the test run, but that one keeps crashing. Any idea why that might be the case? I've already tried reinstalling exoplasim and downgrading to 3.2.4
Here is my console feedback:
Checking for /home/user/.local/lib/python3.6/site-packages/exoplasim/plasim/run/most_plasim_t21_l5_p4.x....
Mean Molecular Weight set to 28.9703 g/mol
rm: cannot remove '/home/user/mymodel_testrun/plasim_restart': No such file or directory
--------------------------------------------------------------------------
[[7230,1],1]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:
Module: OpenFabrics (openib)
Host: linux
Another transport will be used instead, although this may result in
lower performance.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec has exited due to process rank 0 with PID 8536 on
node linux exiting improperly. There are three reasons this could occur:
1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.
2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"
3. this process called "MPI_Abort" or "orte_abort" and the mca parameter
orte_create_session_dirs is set to false. In this case, the run-time cannot
detect that the abort call was an abnormal termination. Hence, the only
error message you will receive is this one.
This may have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).
You can avoid this message by specifying -quiet on the mpiexec command line.
--------------------------------------------------------------------------
[linux.fritz.box:08533] 3 more processes have sent help message help-mpi-btl-base.txt / btl:no-nics
[linux.fritz.box:08533] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
Command '['mpiexec -np 4 most_plasim_t21_l5_p4.x']' returned non-zero exit status 1.
Traceback (most recent call last):
File "/home/user/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 930, in _run
subprocess.run([self._exec+self.executable],shell=True,check=True)
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['mpiexec -np 4 most_plasim_t21_l5_p4.x']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "program.py", line 4, in
mymodel.run(years=10,crashifbroken=True)
File "/home/user/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 495, in run
self._run(**kwargs)
File "/home/user/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1027, in _run
self._crash() #Bring in the cleaners
File "/home/user/.local/lib/python3.6/site-packages/exoplasim/__init__.py", line 1869, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
RuntimeError: ExoPlaSim has crashed or begun producing garbage. All working files have been moved to /home/user/mymodel_crashed/
[1]+ Done kate program.py
I've seen one or two people hit this error before and it seems to come down to some issue with how openmpi is installed but frankly I'm not sure exactly how one solves it.
DeleteI got it to work now. Reinstalling Linux fixed it for me.
DeleteAmazing resource and brilliant tutorial - just wanted to confirm, I'm having the exact same error issue as the few people above. Not entirely sure how to go about things next, other than pull the old call tech support?
ReplyDeleteIs there currently a way to have the Koppen pasta script output the interpolated and topography adjusted temperature maps? (or other maps like precipitation?). I'm reasonably comfortable in Python, so I can probably handle mucking around in the scripts if not but I don't want to reinvent the wheel - it looks like the "tas" variable is the one to use for temp at least (which is monthly temperatures for each point?)
ReplyDeleteIt's not designed to do so, but if you have the script set to do the interpolation than at around line 900 in the script it should have the adjusted temperature data in a numpy array also named "tas" that you could write out to an appropriate format. For anything else it's probably easier to just go directly to the netcdf file, there's not any sort of adjustment of precipitation in the script.
DeleteThanks! Appreciate all the great work
DeleteI've recently upgraded my machine and now I'm running into difficulty reinstalling exoplasim. I think I've isolated the error somewhere in this block, but I can't make head nor tail of it. Googling most parts of it returns this very page as one of the first results!
ReplyDeletePRODUCING: -r8 -o most_plasim_t21_l10_p8.x
Writing resmod.f90.....
rm: plasim.x: No such file or directory
rm: ../bin/most_plasim_t21_l10_p8.x: No such file or directory
rm: ../run/most_plasim_t21_l10_p8.x: No such file or directory
cp: ../src/specs is a directory (not copied).
Writing makefile...
mpif90 -c -O3 -cpp -fcheck=all -ffixed-line-length-132 -ffpe-trap=invalid,zero,overflow -ffpe-summary=none -finit-real=zero -fdefault-real-8 resmod.f90
mpif90 -c -O3 -cpp -fcheck=all -ffixed-line-length-132 -ffpe-trap=invalid,zero,overflow -ffpe-summary=none -finit-real=zero -fdefault-real-8 plasimmod.f90
mpif90 -c -O3 -cpp -fcheck=all -ffixed-line-length-132 -ffpe-trap=invalid,zero,overflow -ffpe-summary=none -finit-real=zero -fdefault-real-8 mpimod.f90
mpimod.f90:569:11:
569 | use mpimod
| 1
Error: 'mpi_info' of module 'mpimod', imported at (1), is also the name of the current program unit
mpimod.f90:569:11:
569 | use mpimod
| 1
Error: Name 'mpi_info' at (1) is an ambiguous reference to 'mpi_info' from current program unit
make: *** [mpimod.o] Error 1
cp: plasim.x: No such file or directory
cp: ../bin/most_plasim_t21_l10_p8.x: No such file or directory
I've been having the same issue, did you ever manage to figure it out?
DeleteWhat do you think would be the best way to go about configuring a model run for planet scenarios in which the orbital period and rotational period are almost but not quite tidally locked? For example, something like Venus, in which the rotational period of the planet is a very substantial portion of the year length (90-99%). In scenarios like this the Synodic Day (Sunrise to Sunrise) can be many earth years long.
ReplyDeleteShould we try to capture the Synodic Day length in the the runstep setting? Or perhaps equate Synodic Day to a month division? Is getting a clean division of rotational periods into runsteps or months even needful? I'm unsure what makes the most sense from the perspective of interpreting the output with the climate script, since year/day/cycles is so very different in this scenario from both Earth and from Tidal Lock.
In principle you should set rotationperiod to the actual sidereal rotation period, synchronous to true, and add desync to the appropriate value of apparent movement of the sun in degrees per minute to replicate your synodic day length. Honestly though, there seems to sometimes be odd timekeeping issues with this, so a while back I made some alternate files you can add to a fresh install of exoplasim https://www.patreon.com/posts/exoplasim-86570701 which then allow for you to set an exact number of solar days per orbit rather than relying on the desync parameter.
DeleteIn terms of getting the climate script to work well with it, that's a trickier question and I'm not sure there's a single best answer. You'd want to sample over multiple years, because in this situation climate cycles may last more than one orbit, but the script isn't really designed to handle that; give it multiple input years and it'll just average them together and treat the result as a single year, which isn't great if the warm and cold periods are happening at different times of the year across files. One thing I may attempt in the future is an option for the script to instead go year-by-year finding important climate parameters and then averaging those results together afterwards, but that's pretty far back on my backburner right now.
Thanks for the code. That looks super helpful. Though it looks like the major problem this code is out to solve are timekeeping issues with spin-orbit resonances other than 1:1? Is this timekeeping issue a problem for simulations in which there isn't an actual spin-orbit resonance? Could you clarify what this odd timekeeping behavior impacts? Why not just set desync to false, and accurately adding the rotation rate and orbital period (again for non spin-orbit scenarios)?
DeleteIn case it helps, the real-world setups I'm trying to sim are those in which gravitational interactions between planets in close-packed systems induce a faster/slower rotation for planets that would otherwise form tidal lock. From some papers I've read, this is likely the situation for many planets in such systems, particularly if they have substantial eccentricities, but not quite substantial enough to induce capture into higher order spin-orbit resonance (like Mercury into the 3:2). So it could be something like a planet with a year of 45 days, a rotation of 44.2 days, and an eccentricity of 0.07. No actual spin-orbit resonance.
So far as I can tell, in regular runs exoplasim regards rotationperiod as both the sidereal and synodic day, which is a fine enough approximation if there are many days per year but obviously an issue for a case like yours. You could set it to the synodic day, but then the coriolis forces won't be accurate to your actual rotation period. (and honestly I think some weirder issues may crop up when day length approaches year length based on one attempt I made to test a 9:10 resonance, but I never investigated further). With synchronous=True, rotationperiod is still used to determine coriolis forces but ignored for purposes of insolation. desync shifts the insolation each timestep, but in a way that may not always be perfectly accurate over long periods, so I implemented the soldaysperorb parameter in a separate manner that should be more consistent; this admittedly doesn't matter as much when you're not interested in exact resonances, but at any rate I'm pretty sure it should work fine with any arbitrary number without having to be an exact resonance--but I haven't tested this fully. Whatever you try, be sure to check the czen parameter in the output to check the insolation is moving like you expect.
DeleteWould appreciate any ideas on what's wrong...
ReplyDeleteToday exoplasim just started crashing when running any new simulations. As far As I can determine it crashes whenever I create a sim that both 1) uses any map AND 2) doesn't match the runsteps/timestep/otherargs of a previous simulation. In other words if I change these three parameters the model will crash. For example if I cut the runsteps of a model in half (changing nothing else), the model will crash. If I cut the year length in half (to match the new runsteps) the model will also crash, despite the fact that the runsteps and model year exactly match. I have zero clue what's happen. It's utterly baffling and doesn't seem to make any sense at all.
Here is an example of the crash report (it varies depending on how I change parameters, along with when exactly the crash happens, but this is one of the types of crashes that keeps happening):
Command '['mpiexec -np 4 most_plasim_t21_l10_p4.x']' returned non-zero exit status 136.
Traceback (most recent call last):
File "/Users/username/Library/Python/3.9/lib/python/site-packages/exoplasim/__init__.py", line 805, in _run
subprocess.run([self._exec+self.executable],shell=True,check=True,
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['mpiexec -np 4 most_plasim_t21_l10_p4.x']' returned non-zero exit status 136.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/username/Desktop/test_runs/run_tester706_9A.py", line 124, in
model.run(years=28, crashifbroken=True)
File "/Users/username/Library/Python/3.9/lib/python/site-packages/exoplasim/__init__.py", line 387, in run
self._run(**kwargs)
File "/Users/username/Library/Python/3.9/lib/python/site-packages/exoplasim/__init__.py", line 885, in _run
self._crash() #Bring in the cleaners
File "/Users/username/Library/Python/3.9/lib/python/site-packages/exoplasim/__init__.py", line 1705, in _crash
raise RuntimeError("ExoPlaSim has crashed or begun producing garbage. All working files have been moved to %s_crashed/"%(os.getcwd()+"/"+self.modelname))
An example of this weird problem. These parameters run perfectly fine:
Deleterotation = 1.0
year = 55.0
runsteps = 6480
timestep = 40
otherargs = {'NSTPW@plasim_namelist':'180'}
But if I change year to 180.0 (which is what it should be to match the runsteps) then the model crashes with the output I previously posted. I don't get why some combinations that should work are not while others are.
Another example:
Deletecannot reshape array of size 202752 into shape (9,10,32,64)
cannot reshape array of size 202752 into shape (9,10,32,64)
Error writing output to MOST_SNAP.00000.nc; log written to postprocess.log
I got this when I changed a few parameters in a case file that also uses a custom map file. The paramaters I changed were runsteps and year length, nothing else. The first file runs the case works while the altered file just crashes with the above error.
The source code mentions "albedomap." Are we able to input a .sra file to set the land albedo (or land & water)? Ever try this? This could be useful for simulating lots of climates. It'd be cool to set land albedo to different values to account for things like sand-dune filled deserts, lava fields, etc.
ReplyDeleteI think you can set albedo manually a few different ways, but the model already adjusts albedo based on surface moisture, ice and snow, and (if you have the vegetation model activated) vegetation cover, which you'd override if you did this.
Delete