A Remarkably Tiny Global Circulation Model You Can Run

So I’ve got my infrastructure Pi boards all in a dogbone rack, and I’ve got my Desktop system on a Pi Model 3 and find it good enough as a Daily Driver (still tuning the preferred ‘release’ to run, at the moment wandering between Arch, Debian, and Devuan as the mood strikes me or depending on where I’ve left a bit of something…)

So I figured maybe it’s time to set about using all these cores. (I’ve got ‘top’ running in three windows from 3 of the 4 Pi boards and seeing them all at 99% idle is, well, it offends my sense of waste-not want-not…)

I’ve made GIStemp ‘go’ before, so on the docket is “do it again” with the more recent version (AND finish the conversion to Little Endian in Step 4-5 block that I never finished… I got ‘distracted’ by the discovery that the ‘magic sauce’ data molestation was moving upstream into the GHCN, USHCN and all the little National HCNs from around the world… and spent a year or three doing ‘dig here!’ in that…) So that’s to be done “sometime”. But it takes nearly no CPU to run GIStemp. See:

https://chiefio.wordpress.com/2010/08/09/obsolescent-but-not-obsolete/

for a photo and description of the workstation I’d done the first port on. Pentium class AMD CPU at 400 MHz with 128 MB of memory. Yes, far less than the modern Raspberry Pi… But I’d already DONE a trial run at the port-to-the-Pi, and the old code complied fine:

https://chiefio.wordpress.com/2015/07/29/raspberry-pi-gistemp-it-compiled/

Raspberry Pi GIStemp – It Compiled
Posted on 29 July 2015 by E.M.Smith

I’ve not done any testing yet, just a first cut “unpack and compile”.

The good news is that it did, in fact, compile. And STEP0 ran.

I had the same two “Makefile” issues from the port to Centos (Red Hat for the Enterprise). No surprise as it was an unpack of the same tar file archive with the same two issues in it. A bogus “:q” from a botched exit from the editor in one source file, and the need to remove a trace directive from the compile statement on another. After that, it compiled fine with one warning.

That warning might be a significant bug in the GIStemp code. I’ll need to investigate it further. I don’t remember if any of the other compilations found that type mis-match. The importance of it is still TBD and might be nothing.

Here’s the captures on what I did:

So re-doing that on a faster Pi with the newest code seemed a bit thin gruel…

What I really wanted was a GCM to play with. Get into the whole idea of what is it these things do. Maybe put in a “GOSUB Solar_Cycle” in place of CO2, tune a bit, and present an alternative computer fantasy to the AGW one.

The Model E code is the biggest GCM (Global Circulation Model) where I’ve found easy to get public domain source code. But it isn’t promising for a stack of 3 x Pi boards…

http://www.giss.nasa.gov/tools/modelE/

GISS GCM ModelE

The current incarnation of the GISS series of coupled atmosphere-ocean models is available here. Called ModelE, it provides the ability to simulate many different configurations of Earth System Models — including interactive atmospheric chemistry, aerosols, carbon cycle and other tracers, as well as the standard atmosphere, ocean, sea ice and land surface components.
[…]

Download

Model versions used for the CMIP5 and CMIP6 simulations are available via the nightly snapshots of the current code repository, including the frozen ‘AR5_branch’. However, users should be aware that these snapshots are presented ‘as is’ and are not necessarily suitable for publication-quality experiments.

Please let us know if you intend to use this code by subscribing to our mailing list. We will then keep you (very occasionally) informed about code patches and possible improvements to the configuration.
Guidelines for Use of Model Code

Our code is freely available for download and use. Note however, that this is a work in progress and many people contribute to its development. It’s important to state how much the group effort — in all the different aspects of modeling — has contributed to progress. From the people who conceive of new developments, the people who code them, the people that apply the model to new science questions, the people who find the inevitable bugs, to those who do the data processing and analyse the diagnostics, all are essential to keeping the project viable. This should be reflected on when deciding on co-authorship and acknowledgments.

When you look down into the ‘configuration’ of computer desirable, you find:

https://simplex.giss.nasa.gov/gcm/doc/UserGuide/System_requirements.html

System requirements

The ModelE source code is quite portable and can be installed and used basically on any Unix machine with enough CPU power and memory (from Linux clusters to Linux and Mac OS X desktops). Though one can run the basic serial version of the model with prescribed ocean on a single core with as little as 2 GB of memory, to do any useful simulations in reasonable time one would need a computer with at least 16 cores (Sandy Bridge or faster) with at least 1 GB of memory per core. To do dynamic ocean simulations with full atmospheric chemistry one typically would need 88 cores with at least 1 GB of memory per core.

The source code is written mostly in Fortran 90 language with some elements of Fortran 2003 and can be compiled either with Intel ifort compiler (version 12.0) or with GNU gfortran (version 4.9 or later).

For input/output we use a NetCDF library, so it has to be installed (version 3.6 or later).

For parallel simulations on multiple cores the model needs to be compiled with MPI support, so an MPI library needs to be installed on your computer. The following MPI distributions are currently supported by the model:

OpenMPI
Intel
MPICH2
MVAPICH2
SCALI
mpt

For desktops or small servers we would recommend OpenMPI, since it is the easiest one to install and configure, though MPICH2 also works without problems. On a cluster, typically it would be up to support group to make a decision on which MPI distribution is more suitable for a particular platform. Over the last few years we were using Intel MPI with great success.

The compilation process is based on GNU make command and uses perl scripting language and m4 preprocessor (GNU version). Typically these are present by default on any Linux or Mac OS X system, but if you are using other type on Unix you may need to install them.

If instead of latitude-longitude version of the model you want to work with cubed sphere version, then in addition to the requirements mentioned above you will need to install a compatible ESMF library. You will also need to obtain the source code for the cubed sphere dynamical core from the developers since it is not included in the standard modelE distribution.

As I’ve already gotten Fortran 90 and OpenMPI to run on the Pi, that’s not an issue. BUT, that 88 cores and 88 GB of memory is ‘an issue’ for a Pi Cluster. ASSUMING I’m willing to wait longer for results and that a background process running for a week or three is OK by me, not by them: That might let me use a Pi Model 3 with GB memory (lite on memory / core by 3 GB, so add swap…) and then it’s only 88/4 = 22 Pi Model 3 boards and the 6 Dogbone Cases to hold them… Er, a bit larger than my kit today… Even dropping back to the 16 cores and 16 GB is 4 cores more than I’ve got, and much much faster cores too… So I’m about a factor of 10 behind where I’d really need to be. Not where you want to make your first test run at a technology…

I could likely make their minimal run version “go”, and that’s where I’ll start whenever I return to Model E… but not now. Just below Model E on their page, you find a reference to an older model. Off to the side of that page at the NASA, one finds a link to it:

http://www.giss.nasa.gov/tools/modelii/

GISS GCM Model II

The Goddard Institute for Space Studies General Circulation Model II, described fully by Hansen et al. (1983), is a three-dimensional global climate model that numerically solves the physical conservation equations for energy, mass, momentum and moisture as well as the equation of state.

Hmmm… 1983 isn’t all that long ago. Clearly this model has been used for Global Warming calculations. Looks like a good place to start, to me. Yes, it’s about 30 years back, but it ought to contain the basics. It would also be more approachable from the POV of figuring out how their thinking evolved.

Model Description

The standard version of this model has a horizontal resolution of 8° latitude by 10° longitude, nine layers in the atmosphere extending to 10 mb, and two ground hydrology layers. The model accounts for both the seasonal and diurnal solar cycles in its temperature calculations.

Cloud particles, aerosols, and radiatively important trace gases (carbon dioxide, methane, nitrous oxides, and chlorofluorcarbons) are explicitly incorporated into the radiation scheme. Large-scale and convective cloud cover are predicted, and precipitation is generated whenever supersaturated conditions occur.

Snow depth is based on a balance between snowfall, melting and sublimation. The albedo of snow is a function of both depth and age. Fresh snow has an albedo of 0.85 and ages within 50 days to a lower limit of 0.5. The sea ice parameterization is thermodynamic with no relation to wind stress or ocean currents. Below -1.6°C ice of 0.5 m thickness forms over a fractional area of the grid box and henceforth grows horizontally as needed to maintain energy balance. Surface fluxes change the ocean water and sea ice temperature in proportion to the area of a grid cell they cover. Conductive cooling occurs at the ocean/ice interface, thickening the ice if the water temperature remains at -1.6°. Sea ice melts when the ocean warms to 0°C and the SST in a grid box remains at 0°C until all ice has melted in that cell. The albedo of sea ice (snow-free) is independent of thickness and is assigned a value of 0.55 in the visible and 0.3 in the near infrared, for a spectrally weighted value of 0.45.

Vegetation in the model plays a role in determining several surface and ground hydrology characteristics. Probably the most important of these is the surface albedo, which is divided into visible and near infrared components and is seasonally adjusted based on vegetation types. Furthermore, the assigned vegetation type determines the depth to which snow reflectivity can be masked. Hydrological characteristics of the soil are also based upon the prescribed vegetation types; the water holding capacity of the model’s two ground layers is determined by the vegetation type as is the ability of those layers to transfer water back to the atmosphere via transpiration. Nine different vegetation classes, developed by Matthews (1984) for the GISS GCM, represent major vegetation categories and the ecological/hydrological parameters which are calculated from the vegetation. Since the GISS GCM is a fractional grid model, more than one vegetation type can be assigned to each grid box.

Sea surface temperatures (SST) are either specified from climatological input files or may be calculated using model-derived surface energy fluxes and specified ocean heat transports. The ocean heat transports vary both seasonally and regionally, but are otherwise fixed, and do not adjust to forcing changes. This mixed-layer ocean model was developed for use with the GISS GCM and is often referred to as the “Q-flux” parameterization. Full details of the Q-flux scheme are described in Russell et al. (1985), and in appendix A of Hansen et al. (1997). In brief, the convergence (divergence) at each grid cell is calculated based on the heat storage capacity of the surface ocean and the vertical energy fluxes at the air/sea interface. The annual maximum mixed-layer depth, which varies by region and season, has a global, area-weighted value of 127 meters. Vertical fluxes are derived from specified SST control runs where the specified SSTs are from climatological observations and have geographically and seasonally changing values. In the early 1990s Russell’s technique was modified slightly to use five harmonics, instead of two, in defining the seasonally-varying energy flux and upper ocean energy storage. This change improved the accuracy of the approximations in regions of seasonal sea ice formation. The technique reproduces modern ocean heat transports that are similar to those obtained by observational methods (Miller et al. 1983). By deriving vertical fluxes and upper ocean heat storage from a run with appropriate paleogeography and using SSTs based on paleotemperaure proxies, q-fluxes it provides a more self-consistent method for obtaining ocean heat transports from paleoclimate scenarios that use altered ocean basin configurations.

Current Status

Present-day maintenance and some development of Model II is performed within the context of the Columbia University EdGCM project. See the links at right for source code downloads and other resources provided by that project. Historical versions of Model II (e.g., the computer code used in the 1988 simulation runs) are not currently available. Please address all inquiries about the EdGCM project and about implementing Model II on modern personal computers to Dr. Mark Chandler.

Persons interested in using the most recent version of the GISS climate model, a coupled atmosphere-ocean model, should see the ModelE homepage.

Gee… and it is STILL in use, though mostly in a teaching context.

I can live with that.

The “stuff on the right” says:

Downloads & Links

Model II Source Code

The 8°×10° (lat×lon) version of the GISS Model II is still in use as a research tool for paleoclimate and planetary studies, for very long simulations, or where limited computing resources are available. An up-to-date copy of this slightly modified version, with minor updates and bugfixes, is available from the EdGCM project.

EdGCM

The Columbia University EdGCM software is a graphical user interface which simplifies set-up and control of GISS Model II. This educational suite gives users the ability to create and conduct “Rediscovery Experiments”, simulations that reproduce many of the hundreds of experiments that have been conducted and published using this version of the NASA GISS GCM.

EdGCM Model II Forum

Persons attempting to compile the Model II FORTRAN source code may consult the EdGCM message boards for assistance from other model users.

Even has an active Forum for questions. This is not some antique dead code. This is an actively used teaching tool. Just what I’d like to have and where I’d be best served to start.

From their link:

http://edgcm.columbia.edu/

EdGCM provides a research-grade Global Climate Model (GCM) with a user-friendly interface that can be run on a desktop computer. For the first time, students can explore the subject of climate change in the same way that actual research scientists do. In the process of using EdGCM, students will become knowledgeable about a topic that will surely affect their lives, and we will better prepare the next generation of scientists who will grapple with a myriad of complex climate issues.

Our goal is to improve the quality of teaching and learning of climate-change science through broader access to GCMs, and to provide appropriate technology and materials to help educators use these models effectively. With research-quality resources in place, linking classrooms to actual research projects is not only possible, but can also be beneficial to the education and research communities alike.

Just what I’m looking for. If it can run “on a desktop computer” it can run on a Pi (though perhaps more slowly…)

If even looks like, for the less adventuresome, you can just run it on your Mac or PC without the porting work:

http://edgcm.columbia.edu/software2/

Software

EdGCM, or the Educational Global Climate Model, is a suite of software that allows users to run a fully functional 3D global climate model (GCM) on laptops or desktop computers (Macs and Windows PCs). Teachers, students and others can learn-by-doing to design climate experiments, run computer simulations, post-process data, analyze output using scientific visualization tools, and report on their results. All of this is done in the same manner and with the same tools used by climate scientists.

Click here for details about the specific components of the EdGCM software

The Global Climate Model (GCM) at the core of EdGCM was developed at NASA’s Goddard Institute for Space Studies, and has been used by researchers to study climates of the past, present and future. EdGCM makes it possible for people to use the GCM without requiring programming skills or supercomputers. Major components of the software include:

A graphical user interface to manage all aspects of working with the GCM.
A searchable database that organizes experiments, input files, and output data.
Scientific visualization software for mapping, plotting and analyzing climate model output.
An eJournal utility to help create reports or instructional materials (including images).
Automated conversion of graphics and reports to html for web publishing.

EdGCM also comes complete with 6 ready-to-run climate model experiments:

2 modern climate simulations
3 global warming simulations
1 ice age simulation

and educators have great flexibility in constructing their own scenarios to satisfy specific curricular requirements. EdGCM scales for use at levels from middle school to graduate school, making it a unique tool for bringing a real research experience into the classroom.

Me? I want to compile this from scratch as my intent is to add some bits to it from the Solar and Planetary Cycles POV. Hey, we need a “computer model run” to bash the AGW folks with just like they have been pushing their stuff at us…

http://edgcm.columbia.edu/ModelII/Compile.html

Has a load of OS X Intel and OS X PPC and more. Also some PC bits. For Linux they want you to run it under wine:

OS X GNU Fortran

This platform is not officially supported. There is a Makefile.gfortran in the source directory which works at the time of this writing. You’ll need to edit RANVAX.f and setpath.f to remove some “_”‘s.

GNU Tools w/ CygWin (Unofficial compile)

See http://forums.edgcm.columbia.edu/ for comments and user suggestions on building with CygWin

Linux (Wine)

You cannot run EdGCM on Linux but you can run Model II. The following instructions are thanks to Patrick Lee

Create a run on Windows, suppose the name of the run is testrun
Run the simulation for the first hour and then stop the simulation. 3.Transfer the whole directory ..\EdGCM 4d\EdGCM 3.0\Output\testrun to Linux. You may delete the file GCM-testrun.exe which is the Lunar (the file testrun.exe is model II) and WhatToStart.TXT. If there is a file called SSW.STOPGCM, then you MUST delete it.
Use wine to run the testrun.exe on Linux (Notice that model is a command line program, so you should not be afraid when you see the black screen).

OK, so “some assembly required”, but it is known to be runnable under GNU Fortran and that’s my target language. As Fortran is highly portable, I’m thinking this likely is not all that hard to port, and these folks just love expensive Macs… “We’ll See” when the compile time comes…

So I downloaded it. And unpacked it.

[root@ARCH_pi_64 trunk]# ls -l /GCM
total 304
drwxr-xr-x 3 root root   4096 Dec 26 23:20 GCM
-rw-r--r-- 1 root root 303284 Dec 26 23:20 modelII_source.zip

OK, it’s a zip file of 303 KB. Not big, really. Unzipped with ‘unzip’ it makes a directory named “GCM”. Wandering down it, you get to:

[root@ARCH_pi_64 trunk]# pwd
/GCM/GCM/modelII/trunk

(Note I named my working dir /GCM before I knew what it would do, so I have a double dip on GCM at the top of the path…)

[root@ARCH_pi_64 trunk]# du -ks .
1576	.
[root@ARCH_pi_64 trunk]# ls
B83XXDBL.COM	   Pjal0C9.f
BA94jalC9.COM	   PostBuild.sh
DB11pdC9.f	   R83ZAmacDBL.f
FFT36macDBL.f	   RANVAX.f
FORCINGSjalC9.f    RANVAXxlf.f
FORCINGSmac.COM    README.f.in
Info.plist	   RFRCmacDBL.f
Makefile	   UTILmacDBL.f
Makefile.Mac.PPC   UTILwinDBL.f
Makefile.README    commandlinetest.gui
Makefile.gfortran  modelF.r
Makefile.ifort	   mrweprefs.r
Makefile.win	   pd_COMMON
Makefile.win.gui   setpath.f
Mjal2cpdC9.f

So 1.5 MB of stuff once unpacked (and not including data files). I think I can live with that.

I suspect my biggest hurdles will be the GUI bits. That there is a MAKEFILE for gfortan is a Very Good Thing.

[root@ARCH_pi_64 trunk]#  cat Makefile.gfortran 

F77COMPILER= gfortran
LINKER =    gfortran
F77_FLAGS =   -c -s -fconvert=big-endian -fno-automatic -ff2c -O2
# ifort  -O2   -convert big_endian       -IPF_fma  -save  -zero  -ftz  -assume 
# dummy_aliases  -align none -mp      -openmp   -c L23_DAILY_MClim_CH4mths.f  

LIBS = -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
TARGET=      model.command

SRCS = RANVAX.f \
	setpath.f \
	RFRCmacDBL.f \
	UTILmacDBL.f \
	Mjal2cpdC9.f \
	Pjal0C9.f \
	FORCINGSjalC9.f \
	FFT36macDBL.f \
	R83ZAmacDBL.f \
	DB11pdC9.f \
	README.f
OBJS = $(SRCS:.f=.o)           # all objects

%.o: %.f
	$(F77COMPILER) -o $@ $(F77_FLAGS) $<

$(TARGET): $(OBJS)
	$(LINKER) $(LPATHS) $(OBJS) $(LNK_FLAGS) $(LIBS) -o $(TARGET)

clean:
	rm -f *.o
	rm -f $(TARGET)

.PHONEY: all clean

Looks pretty straight forward and simple. I think I can work with that.

As I already have gfortran installed under Arch Linux, I’m doing my first whack at it here. Once that works, I’ll try moving the whole thing over to Devuan on the Model 2 (assuming things are fast enough…)

So that’s where I’m at and what I’m doing for the next day or three…

The description of the Input Files here:

http://edgcm.columbia.edu/ModelII/InputFiles.html

Gives an interesting POV of what is set at the start, and how many parameters you can play with (lots!).

You can download the source zip file from:

http://edgcm.columbia.edu/ModelII/modelII_source.zip

Then there’s a lot of documentation links on their top page for the model… So some “light reading” for the rest of the year… that thankfully is only a few more days ;-)

So that’s what I’m ‘up to’ for the next while. Seeing if I can make a Pi Port of this go, then seeing how hard it might be to splice on a Solar Cycle routine… As in all things software “We’ll see” ;-)

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in AGW and GIStemp Issues, GCM, Tech Bits and tagged , , , . Bookmark the permalink.

50 Responses to A Remarkably Tiny Global Circulation Model You Can Run

  1. Larry Ledwick says:

    Hmmm interesting project – just a thought
    If you were to specify the specific Pi board you wanted to use, and case (amazon order number for example) and sort of mention a UPS mail drop address, Santa might send you a few bits and pieces for an 88 core system as Santa’s elves from time to time might send your way via drop ship to that address.

  2. p.g.sharrow says:

    Larry Ledwick says:
    27 December 2016 at 1:18 am;”Santa’s elves from time to time might send your way ”

    I am now ready to assist with that or donate through paypal.

    Be careful about the things you might wish for!.
    you might just get it…pg

  3. kneel63 says:

    ‘Twere it me, I’d be very interested in seeing what happens when you “tweak” the ocean circulation timeframes as well as the solar – my own mental model is that the majority of climate “change” is driven by the “beat” between these two. Kinda like: slightly bigger solar = warming ocean surface, “sucked down” and a series of “stripes” in that circulation. As each “stripe” re-surfaces, it obviously affects the starting point for ocean surface temps. A complex “dance”, also potentially modulated by circulation variations due to lunar tidal cycle too – so maybe not always the same length-of-cycle. Call it (wild-ass guess) 700 years ocean cycle, 1100 year solar and 60 year lunar. That makes for a fairly complex waveform when viewed over 10K+ years.
    Of course you have your own ideas, just throwing stuff out there – mayhap is Santa is nice re: Pi’s, I will get my Xmas wish too ;-)

  4. pearce m. schaudies says:

    Hi Chief. Greetings from the Big Mango (BKK).
    Running the GC am on a desktop sounds like it will be a ton of fun. For the one week to 2 week run times you may want to consider battery float or uninterruptible power supply haha.

    I hope you can add in the solar cycle and that other thing. It would be way cool if you could simulate the little Ice Age, eh.

    I noticed the following statement regarding the ocean simulation Theory, this may require some tweaking if it doesn’t give you desired result.

    The ocean heat transports vary both seasonally and regionally, but are otherwise fixed, and do not adjust to forcing changes. This mixed-layer ocean model was developed for use with the GISS GCM and is often referred to as the “Q-flux” parameterization. Full details of the Q-flux scheme are described in Russell et al. (1985), and in appendix A of Hansen et al. (1997). In brief, the
    x
    Regards, Pearce M. Schaudies.
    Minister of Future

  5. E.M.Smith says:

    @Elves:

    Well, first I need to make this little one go… then assess the difficulty of reaching the goal SW config… then choose ‘best hardware’… (Basically time out the speed of an ARM vs Intel arch chip … i.e. one run on the Pi one on the Laptop… and x cost / mip…)

    I also need to look at the loop structure in the code. IFF it is amenable to GPU handling, then it is most likely a single $150 or so NVIDIA kit would do it.

    So a while to go before I can assure any Elves that they are actually doing anything other than making my office look kool ;-)

    But I’m banking that offer “for that day”… (from 3 days fo the Condor…)

    @kneee63:

    Yup, lots of things you can do with the basic running system “just to see”. One I’m hoping to try is shut off CO2, then compare the result to the solar cycle long cycles. Is there an “inverse match” indicating they need to be added in?…

    @Pearce:

    Power here is pretty stable (once we pitched out Gov. Grey “out” Davis and his playing with the electric grid…) so when I shut down the Pi Model 1 to put it in the dogbone case, it had been running a couple of months (basically since I’d last put Alpine on it and put it into production). Prior to that, the Debian version had near a year uptime on it IIRC.

    BUT, if it comes time for really long runs of more than that, I’ve got a killowatt UPS that just needs a battery, and a new battery just sitting in a car from Florida with nothing else to do, so I can make a kW UPS without about a 4 week run time, that float charges when there is power; and all in about 2 work hours…

    @All:

    Some sizing:

    ( wc -l gives number of lines in a file)

    [root@ARCH_pi_64 trunk]# wc -l *  
         81 B83XXDBL.COM
         63 BA94jalC9.COM
       6750 DB11pdC9.f
        378 FFT36macDBL.f
        175 FORCINGSjalC9.f
         36 FORCINGSmac.COM
         30 Info.plist
         31 Makefile
         32 Makefile.Mac.PPC
        107 Makefile.README
         34 Makefile.gfortran
         36 Makefile.ifort
        337 Makefile.win
          4 Makefile.win.gui
       2961 Mjal2cpdC9.f
       4146 Pjal0C9.f
          1 PostBuild.sh
       6928 R83ZAmacDBL.f
         42 RANVAX.f
         46 RANVAXxlf.f
         80 README.f.in
       1604 RFRCmacDBL.f
        131 UTILmacDBL.f
        131 UTILwinDBL.f
         35 commandlinetest.gui
        503 modelF.r
         77 mrweprefs.r
          3 pd_COMMON
         36 setpath.f
      24818 total
    

    So only 4 big modules, really. 7 different Makefiles (only one of which is likely needed by me). Some COMMON blocks (the things with .COM endings) for passing data between FORTRAN programs. Then 8 small FORTRAN programs, one .sh shell script, and whatever .gui is. Oh, and the README file. Looks pretty easy. Though 6000 lines is about 100 pages… I hope a lot of it is comments and whitespace ;-) At 50 lines / page, that 24,000 lines is 580 pages, or about 1000 pages on a 24 line terminal screen window. Small for a Russian Novel ;-)

    In the gfortran Makefile, this is the most bothersome item:

    LIBS = -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib

    I suppose that’s something to do with the gui stuff… but needs checking. SDK is Software Development Kit typically, so maybe not.

    In the .win version it has:

    DFLT_LIBS= unix.lib vms.lib absRT0.lib kernel32.lib fio.lib fmath.lib comdlg32.lib f90math.lib libac.lib

    The mac PPC (PowerPC) version has:

    LIBS = -lU77 -lV77 -L”$(ABSOFT)/lib” -lf90math -lfio -lf77math -lm

    so maybe it’s just the needed FORTRAN libraries, in which case I’m likely home free as Linux has all that pretty much built in.

    A brute force trial compile (just to surface errors out the gate) using

    for i in *.f
    do
    gfortran $i
    done
    

    mostly gave warnings, but also some errors. It looks related to the ‘advice’ on one of the pages that one of the equipment choices would require removing some underscores… Once one fails to compile, the others may fail due to it not existing yet…

    This is a long list of output, but useful to document what happens with a straight compile and no attempt at making things match the system:

    [root@ARCH_pi_64 trunk]# for i in *.f
    > do
    > gfortran $i
    > done
    DB11pdC9.f:2839:36:
    
           CALL JKMAPS (1,PMO,AJK(1,1,3),ONES,BYP,ONES,KM,2,1,
                                        1
    Warning: Rank mismatch in argument 'scale' at (1) (scalar and rank-1)
    DB11pdC9.f:4288:16:
    
           CALL MEM (WAVE(1,1,N,KQ),IDACC9,MMAX,NUAMAX,NUBMAX,POWER,FPE,
                    1
    Warning: Type mismatch in argument 'series' at (1); passed REAL(8) to COMPLEX(8)
    DB11pdC9.f:4329:16:
    
           CALL MEM (WAVE(1,1,N,KQ),IDACC9,MMAX,NUAMAX,NUBMAX,POWER,FPE,
                    1
    Warning: Type mismatch in argument 'series' at (1); passed REAL(8) to COMPLEX(8)
    DB11pdC9.f:5047:19:
    
           COMMON/WORK2/SMAP(IM,JM),SMAPJ(JM)
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (3552 vs 31248 bytes)
    DB11pdC9.f:4112:20:
    
           COMMON/DILTTL/TITLE(1)
                        1
    Warning: Named COMMON block 'dilttl' at (1) shall be of the same size as elsewhere (64 vs 1024 bytes)
    DB11pdC9.f:3864:20:
    
           COMMON/DJLCOM/JLAT(JM,2),WTJ(JM,2,2),
                        1
    Warning: Named COMMON block 'djlcom' at (1) shall be of the same size as elsewhere (984 vs 192 bytes)
    DB11pdC9.f:3866:20:
    
           COMMON/DJLTTL/TITLE(1)
                        1
    Warning: Named COMMON block 'djlttl' at (1) shall be of the same size as elsewhere (64 vs 7296 bytes)
    DB11pdC9.f:3863:19:
    
           COMMON/WORK4/MLAT(JM),FLAT(JM),ASUM(JM),FHEM(2),HSUM(2)
                       1
    Warning: Named COMMON block 'work4' at (1) shall be of the same size as elsewhere (512 vs 432 bytes)
    DB11pdC9.f:3263:20:
    
           COMMON/DJKTTL/TITLE(1)
                        1
    Warning: Named COMMON block 'djkttl' at (1) shall be of the same size as elsewhere (64 vs 2816 bytes)
    DB11pdC9.f:3258:19:
    
           COMMON/WORK4/MLAT(JM),FLAT(JM),ASUM(JM),AHEM(2)
                       1
    Warning: Named COMMON block 'work4' at (1) shall be of the same size as elsewhere (496 vs 512 bytes)
    DB11pdC9.f:3259:19:
    
           COMMON/WORK5/FKEY(JM,LM),DSJK(JM,LM,2),DSHEM(2,LM,2),
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (7344 vs 1728 bytes)
    DB11pdC9.f:333:19:
    
           COMMON/WORK2/PK(IM,JM,LM),W(IM,JM,LM),PHIE(IM,JM,LM-1),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (199392 vs 31248 bytes)
    DB11pdC9.f:342:19:
    
           COMMON/WORK5/DUT(IM,JM,LM),DVT(IM,JM,LM),
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (256336 vs 7344 bytes)
    DB11pdC9.f:1312:19:
    
           COMMON/WORK2/PK(IM,JM,LM),W(IM,JM,LM),PHIE(IM,JM,LM-1),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (202392 vs 199392 bytes)
    DB11pdC9.f:1319:19:
    
           COMMON/WORK5/DUT(IM,JM,LM),DVT(IM,JM,LM),
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (258784 vs 256336 bytes)
    DB11pdC9.f:2679:19:
    
           COMMON/WORK2/SENDEG(IM,JM),CN(2,IMH+1),BYP(JM),BYPV(JM),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (18016 vs 202392 bytes)
    DB11pdC9.f:2683:19:
    
           COMMON/WORK5/FKEY(JM,LM),DSJK(JM,LM,2),DSHEM(2,LM,2),
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (5616 vs 258784 bytes)
    DB11pdC9.f:3596:19:
    
           COMMON/WORK2/SENDEG(IM,JM),CN(2,IMH+1),BYP(JM),BYPV(JM),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (28960 vs 202392 bytes)
    DB11pdC9.f:4191:19:
    
           COMMON/WORK3/PHI(IM,JM,LM),HTRD(IM,6)
                       1
    Warning: Named COMMON block 'work3' at (1) shall be of the same size as elsewhere (63936 vs 125064 bytes)
    DB11pdC9.f:4192:19:
    
           COMMON/WORK4/CN(2,IMH+1),POWER(120),IPOWER(44),XPOWER(43),
                       1
    Warning: Named COMMON block 'work4' at (1) shall be of the same size as elsewhere (40288 vs 512 bytes)
    DB11pdC9.f:4647:19:
    
           COMMON/WORK2/ENDE16(IM,JM,2),PRAVG(IM,JM),PRSD(IM,JM),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (38448 vs 202392 bytes)
    DB11pdC9.f:5213:19:
    
           COMMON/WORK1/PIT(IM,JM),SD(IM,JM,LM-1),PK(IM,JM,LM)
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (124416 vs 62208 bytes)
    DB11pdC9.f:5214:19:
    
           COMMON/WORK2/JLATP(JM),JLATV(JM),SCALE(36),FGLOB(36),FHEM(2,36),
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (4896 vs 202392 bytes)
    DB11pdC9.f:5216:19:
    
           COMMON/WORK3/GBUDG(JM+3,80,4),CNSLAT(JM+3,36)
                       1
    Warning: Named COMMON block 'work3' at (1) shall be of the same size as elsewhere (76896 vs 125064 bytes)
    DB11pdC9.f:5217:19:
    
           COMMON/WORK4/PI(JM),AM(JM),RKE(JM),RMASS(JM),TPE(JM)
                       1
    Warning: Named COMMON block 'work4' at (1) shall be of the same size as elsewhere (960 vs 40288 bytes)
    DB11pdC9.f:5218:19:
    
           COMMON/WORK5/DUT(IM,JM,LM),DVT(IM,JM,LM)
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (124416 vs 258784 bytes)
    DB11pdC9.f:5617:19:
    
           COMMON/WORK3/GBUDG(JM+3,80,4),FATPE(8,2)
                       1
    Warning: Named COMMON block 'work3' at (1) shall be of the same size as elsewhere (69248 vs 125064 bytes)
    DB11pdC9.f:5618:19:
    
           COMMON/WORK5/DUT(IM,JM,LM),DVT(IM,JM,LM),
                       1
    Warning: Named COMMON block 'work5' at (1) shall be of the same size as elsewhere (273384 vs 258784 bytes)
    DB11pdC9.f:6081:19:
    
           COMMON/WORK1/SUM(20),IK(20)
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (240 vs 124416 bytes)
    DB11pdC9.f:6082:19:
    
           COMMON/WORK3/GBUDG(JM+3,80,4),EHIST(20,101)
                       1
    Warning: Named COMMON block 'work3' at (1) shall be of the same size as elsewhere (85280 vs 125064 bytes)
    DB11pdC9.f:6520:19:
    
           COMMON/WORK1/SLP(IM,JM)
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (6912 vs 124416 bytes)
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/cclyU5Fj.o: In function `diaga_':
    DB11pdC9.f:(.text+0xc630): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0xc894): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0xcc50): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0xcd50): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0xd0e8): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0x152d8): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0x15360): undefined reference to `thbar_'
    DB11pdC9.f:(.text+0x1945c): undefined reference to `clocks_'
    /tmp/cclyU5Fj.o: In function `diagb_':
    DB11pdC9.f:(.text+0x194e8): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x22cf0): undefined reference to `frtr_'
    DB11pdC9.f:(.text+0x23330): undefined reference to `clocks_'
    /tmp/cclyU5Fj.o: In function `diagj_':
    DB11pdC9.f:(.text+0x238b4): undefined reference to `expbyk_'
    /tmp/cclyU5Fj.o: In function `diagjk_':
    DB11pdC9.f:(.text+0x2b228): undefined reference to `expbyk_'
    /tmp/cclyU5Fj.o: In function `diagjl_':
    DB11pdC9.f:(.text+0x34e14): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0x37390): undefined reference to `getan_'
    /tmp/cclyU5Fj.o: In function `master.3.diag7a_':
    DB11pdC9.f:(.text+0x37d40): undefined reference to `getan_'
    DB11pdC9.f:(.text+0x38284): undefined reference to `getan_'
    DB11pdC9.f:(.text+0x383e0): undefined reference to `clocks_'
    /tmp/cclyU5Fj.o: In function `diagij_':
    DB11pdC9.f:(.text+0x3a128): undefined reference to `expbyk_'
    /tmp/cclyU5Fj.o: In function `master.4.diag9a_':
    DB11pdC9.f:(.text+0x40798): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0x40d60): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x40db0): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x4174c): undefined reference to `clocks_'
    /tmp/cclyU5Fj.o: In function `master.5.diag5a_':
    DB11pdC9.f:(.text+0x44ee0): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x45010): undefined reference to `getan_'
    DB11pdC9.f:(.text+0x45874): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x45cc4): undefined reference to `frtr_'
    DB11pdC9.f:(.text+0x46744): undefined reference to `expbyk_'
    DB11pdC9.f:(.text+0x4726c): undefined reference to `frtr_'
    DB11pdC9.f:(.text+0x4806c): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x48338): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x48414): undefined reference to `getan_'
    DB11pdC9.f:(.text+0x484ac): undefined reference to `clocks_'
    DB11pdC9.f:(.text+0x48804): undefined reference to `frtr_'
    collect2: error: ld returned 1 exit status
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    collect2: error: ld returned 1 exit status
    FORCINGSmac.COM:35:23:
    
           COMMON/RFORCINGS/
                           1
    Warning: Named COMMON block 'rforcings' at (1) shall be of the same size as elsewhere (20 vs 40 bytes)
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    collect2: error: ld returned 1 exit status
    Mjal2cpdC9.f:2544:19:
    
           COMMON/WORK2/X(IM,JM),XS(IM),Y(IM,JM)                             7513.   
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (14112 vs 34560 bytes)
    Mjal2cpdC9.f:2585:19:
    
           COMMON/WORK2/X(IM,JM),XS(IM)                                      7807.   
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (7200 vs 34560 bytes)
    Mjal2cpdC9.f:1721:19:
    
           COMMON/WORK2/UX(IM,JM,LM),VX(IM,JM,LM),TX(IM,JM,LM),PX(IM,JM)
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (193536 vs 34560 bytes)
    Mjal2cpdC9.f:2138:19:
    
           COMMON/WORK1/PIT(IM,JM),SD(IM,JM,LM-1),PU(IM,JM,LM)               2507.
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (186624 vs 124416 bytes)
    Mjal2cpdC9.f:1976:19:
    
           COMMON/WORK4/FD(IM,JM),FLUXQ(IM),DUMMYS(IM),DUMMYN(IM)            2010.
                       1
    Warning: Named COMMON block 'work4' at (1) shall be of the same size as elsewhere (7776 vs 8352 bytes)
    Mjal2cpdC9.f:1086:19:
    
           COMMON/WORK1/NLREC(256)                                            508.   
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (20480 vs 186624 bytes)
    /tmp/ccSN0RCg.o: In function `master.0.daily_':
    Mjal2cpdC9.f:(.text+0x13e8): undefined reference to `orbit_'
    Mjal2cpdC9.f:(.text+0x158c): undefined reference to `mread_'
    Mjal2cpdC9.f:(.text+0x16bc): undefined reference to `mread_'
    Mjal2cpdC9.f:(.text+0x1a10): undefined reference to `mread_'
    Mjal2cpdC9.f:(.text+0x1b54): undefined reference to `mread_'
    Mjal2cpdC9.f:(.text+0x1de8): undefined reference to `mread_'
    /tmp/ccSN0RCg.o:Mjal2cpdC9.f:(.text+0x1eac): more undefined references to `mread_' follow
    /tmp/ccSN0RCg.o: In function `dynam_':
    Mjal2cpdC9.f:(.text+0x5630): undefined reference to `diaga_'
    Mjal2cpdC9.f:(.text+0x5654): undefined reference to `diagb_'
    /tmp/ccSN0RCg.o: In function `pgf_':
    Mjal2cpdC9.f:(.text+0x57d8): undefined reference to `expbyk_'
    Mjal2cpdC9.f:(.text+0x5994): undefined reference to `expbyk_'
    Mjal2cpdC9.f:(.text+0x5a18): undefined reference to `thbar_'
    Mjal2cpdC9.f:(.text+0x69a0): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x69d8): undefined reference to `diag9d_'
    /tmp/ccSN0RCg.o: In function `advect_':
    Mjal2cpdC9.f:(.text+0x94c4): undefined reference to `thbar_'
    /tmp/ccSN0RCg.o: In function `advecv_':
    Mjal2cpdC9.f:(.text+0x9acc): undefined reference to `diag5f_'
    Mjal2cpdC9.f:(.text+0xbbac): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0xbbe4): undefined reference to `diag9d_'
    Mjal2cpdC9.f:(.text+0xc5ec): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0xc624): undefined reference to `diag9d_'
    /tmp/ccSN0RCg.o: In function `avrx_':
    Mjal2cpdC9.f:(.text+0xf434): undefined reference to `getan_'
    /tmp/ccSN0RCg.o: In function `input_':
    Mjal2cpdC9.f:(.text+0x11c5c): undefined reference to `readme2_'
    Mjal2cpdC9.f:(.text+0x13204): undefined reference to `expbyk_'
    Mjal2cpdC9.f:(.text+0x16130): undefined reference to `dread_'
    Mjal2cpdC9.f:(.text+0x18f98): undefined reference to `dread_'
    Mjal2cpdC9.f:(.text+0x18ffc): undefined reference to `dread_'
    Mjal2cpdC9.f:(.text+0x19294): undefined reference to `dread_'
    Mjal2cpdC9.f:(.text+0x1a930): undefined reference to `rinit_'
    Mjal2cpdC9.f:(.text+0x1a93c): undefined reference to `frtr0_'
    /tmp/ccSN0RCg.o: In function `MAIN__':
    Mjal2cpdC9.f:(.text+0x1e8f8): undefined reference to `setpath_'
    Mjal2cpdC9.f:(.text+0x1e8fc): undefined reference to `readme_'
    Mjal2cpdC9.f:(.text+0x1eb34): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x1edf0): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x1f2e0): undefined reference to `rfinal_'
    Mjal2cpdC9.f:(.text+0x1fe68): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x20ea8): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x20ec0): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x20ef8): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x20f98): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x20fb0): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x20ff8): undefined reference to `diag7a_'
    Mjal2cpdC9.f:(.text+0x210cc): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x210f8): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x210fc): undefined reference to `condse_'
    Mjal2cpdC9.f:(.text+0x2110c): undefined reference to `precip_'
    Mjal2cpdC9.f:(.text+0x21124): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x211a0): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x211c0): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x211c4): undefined reference to `radia_'
    Mjal2cpdC9.f:(.text+0x211dc): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x21260): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x21280): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x21284): undefined reference to `surfce_'
    Mjal2cpdC9.f:(.text+0x21294): undefined reference to `ground_'
    Mjal2cpdC9.f:(.text+0x212a4): undefined reference to `drycnv_'
    Mjal2cpdC9.f:(.text+0x212bc): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x2133c): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x2136c): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x213f0): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x21410): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x214fc): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x21508): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x21524): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x21574): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x21580): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x216ac): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x216b8): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x216c8): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x21744): undefined reference to `diag5a_'
    Mjal2cpdC9.f:(.text+0x21750): undefined reference to `diag9a_'
    Mjal2cpdC9.f:(.text+0x21fa8): undefined reference to `odifs_'
    Mjal2cpdC9.f:(.text+0x21fac): undefined reference to `ostruc_'
    Mjal2cpdC9.f:(.text+0x21fc4): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x223a8): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x22478): undefined reference to `diag4a_'
    Mjal2cpdC9.f:(.text+0x22584): undefined reference to `diag10_'
    Mjal2cpdC9.f:(.text+0x225b4): undefined reference to `diagj_'
    Mjal2cpdC9.f:(.text+0x225d0): undefined reference to `diagjk_'
    Mjal2cpdC9.f:(.text+0x225ec): undefined reference to `diagjl_'
    Mjal2cpdC9.f:(.text+0x22608): undefined reference to `diag7p_'
    Mjal2cpdC9.f:(.text+0x22624): undefined reference to `diagij_'
    Mjal2cpdC9.f:(.text+0x22640): undefined reference to `diag9p_'
    Mjal2cpdC9.f:(.text+0x2265c): undefined reference to `diag5p_'
    Mjal2cpdC9.f:(.text+0x22678): undefined reference to `diag4_'
    Mjal2cpdC9.f:(.text+0x226cc): undefined reference to `diagkn_'
    Mjal2cpdC9.f:(.text+0x228cc): undefined reference to `diagj_'
    Mjal2cpdC9.f:(.text+0x228e8): undefined reference to `diagjk_'
    Mjal2cpdC9.f:(.text+0x22904): undefined reference to `diagjl_'
    Mjal2cpdC9.f:(.text+0x22920): undefined reference to `diag7p_'
    Mjal2cpdC9.f:(.text+0x2293c): undefined reference to `diagij_'
    Mjal2cpdC9.f:(.text+0x22958): undefined reference to `diag9p_'
    Mjal2cpdC9.f:(.text+0x22974): undefined reference to `diag5p_'
    Mjal2cpdC9.f:(.text+0x22990): undefined reference to `diag6_'
    Mjal2cpdC9.f:(.text+0x229ac): undefined reference to `diag4_'
    Mjal2cpdC9.f:(.text+0x22a20): undefined reference to `diagkn_'
    Mjal2cpdC9.f:(.text+0x22a48): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x22fc0): undefined reference to `rfinal_'
    Mjal2cpdC9.f:(.text+0x245e8): undefined reference to `clocks_'
    Mjal2cpdC9.f:(.text+0x24798): undefined reference to `rfinal_'
    collect2: error: ld returned 1 exit status
    Pjal0C9.f:536:19:
    
           COMMON/WORK1/CONV(IM,JM,LM),PK(IM,JM,LM),PREC(IM,JM),TPREC(IM,JM) 
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (138240 vs 262656 bytes)
    Pjal0C9.f:1337:20:
    
           COMMON/RADCOM/VADATA(11,4,3),DGLAT(46),DGLON(72),TMINSR,FULGAS(18)4017.   
                        1
    Warning: Named COMMON block 'radcom' at (1) shall be of the same size as elsewhere (18672 vs 15728 bytes)
    Pjal0C9.f:1328:19:
    
           COMMON/WORK1/CONV(IM,JM,LM),PK(IM,JM,LM),PREC(IM,JM),             4007.   
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (331776 vs 262656 bytes)
    Pjal0C9.f:1332:19:
    
           COMMON/WORK2/CLDSS(IM,JM,LM),CLDMC(IM,JM,LM),TOTCLD(LM)
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (124488 vs 139608 bytes)
    Pjal0C9.f:1890:19:
    
           COMMON/WORK1/CONV(IM,JM,LM),PK(IM,JM,LM),PREC(IM,JM),             4810.   
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (145152 vs 331776 bytes)
    Pjal0C9.f:1892:19:
    
           COMMON/WORK2/UT(IM,JM,LM),VT(IM,JM,LM),DU1(IM,JM),                4812.   
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (138400 vs 139608 bytes)
    Pjal0C9.f:2977:19:
    
           COMMON/WORK1/CONV(IM,JM,LM),PK(IM,JM,LM),PREC(IM,JM),             6007.4  
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (145152 vs 331776 bytes)
    Pjal0C9.f:2979:19:
    
           COMMON/WORK3/E0(IM,JM,4),E1(IM,JM,4),EVAPOR(IM,JM,4)              6008.   
                       1
    Warning: Named COMMON block 'work3' at (1) shall be of the same size as elsewhere (82944 vs 110592 bytes)
    Pjal0C9.f:3715:19:
    
           COMMON/WORK1/CONV(IM,JM,LM),PK(IM,JM,LM)                          6809.   
                       1
    Warning: Named COMMON block 'work1' at (1) shall be of the same size as elsewhere (124416 vs 331776 bytes)
    Pjal0C9.f:3716:19:
    
           COMMON/WORK2/UT(IM,JM,LM),VT(IM,JM,LM),                           6810.   
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (124576 vs 139608 bytes)
    Pjal0C9.f:3919:19:
    
           COMMON/WORK2/Z1OOLD(IM,JM)                                        8510.   
                       1
    Warning: Named COMMON block 'work2' at (1) shall be of the same size as elsewhere (6912 vs 139608 bytes)
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/cc39FfNw.o: In function `master.0.radia0_':
    Pjal0C9.f:(.text+0x12e8): undefined reference to `forset_'
    Pjal0C9.f:(.text+0x1308): undefined reference to `forget_'
    Pjal0C9.f:(.text+0x133c): undefined reference to `rcomp1_'
    /tmp/cc39FfNw.o: In function `condse_':
    Pjal0C9.f:(.text+0x38b0): undefined reference to `expbyk_'
    Pjal0C9.f:(.text+0x40bc): undefined reference to `frtr_'
    Pjal0C9.f:(.text+0x52bc): undefined reference to `thbar_'
    /tmp/cc39FfNw.o: In function `radia_':
    Pjal0C9.f:(.text+0xc39c): undefined reference to `solarforcing_'
    Pjal0C9.f:(.text+0xc54c): undefined reference to `forget_'
    Pjal0C9.f:(.text+0xc570): undefined reference to `rcompt_'
    Pjal0C9.f:(.text+0xc6a4): undefined reference to `rcompj_'
    Pjal0C9.f:(.text+0xc8c8): undefined reference to `randu_'
    Pjal0C9.f:(.text+0xc8d8): undefined reference to `randu_'
    Pjal0C9.f:(.text+0xe718): undefined reference to `rcompx_'
    /tmp/cc39FfNw.o: In function `surfce_':
    Pjal0C9.f:(.text+0x14a38): undefined reference to `dread_'
    Pjal0C9.f:(.text+0x14ccc): undefined reference to `expbyk_'
    Pjal0C9.f:(.text+0x15998): undefined reference to `expbyk_'
    Pjal0C9.f:(.text+0x159f0): undefined reference to `expbyk_'
    Pjal0C9.f:(.text+0x18170): undefined reference to `expbyk_'
    Pjal0C9.f:(.text+0x182d4): undefined reference to `expbyk_'
    /tmp/cc39FfNw.o:Pjal0C9.f:(.text+0x18414): more undefined references to `expbyk_' follow
    /tmp/cc39FfNw.o: In function `odifs_':
    Pjal0C9.f:(.text+0x2db54): undefined reference to `dread_'
    collect2: error: ld returned 1 exit status
    R83ZAmacDBL.f:4637:32:
    
           DATA AUXGAS/1H0,1HL,1HX,1HX/                                      4914.   
                                    1
    Warning: Legacy Extension: Hollerith constant at (1)
    R83ZAmacDBL.f:4637:20:
    
           DATA AUXGAS/1H0,1HL,1HX,1HX/                                      4914.   
                        1
    Warning: Extension: Conversion from HOLLERITH to REAL(8) at (1)
    R83ZAmacDBL.f:4637:24:
    
           DATA AUXGAS/1H0,1HL,1HX,1HX/                                      4914.   
                            1
    Warning: Extension: Conversion from HOLLERITH to REAL(8) at (1)
    R83ZAmacDBL.f:4637:28:
    
           DATA AUXGAS/1H0,1HL,1HX,1HX/                                      4914.   
                                1
    Warning: Extension: Conversion from HOLLERITH to REAL(8) at (1)
    R83ZAmacDBL.f:4637:32:
    
           DATA AUXGAS/1H0,1HL,1HX,1HX/                                      4914.   
                                    1
    Warning: Extension: Conversion from HOLLERITH to REAL(8) at (1)
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/ccDh0fIL.o: In function `therml_':
    R83ZAmacDBL.f:(.text+0x14320): undefined reference to `expbyk_'
    R83ZAmacDBL.f:(.text+0x1432c): undefined reference to `expbyk_'
    R83ZAmacDBL.f:(.text+0x14340): undefined reference to `expbyk_'
    /tmp/ccDh0fIL.o: In function `master.0.rcomp1_':
    R83ZAmacDBL.f:(.text+0x25390): undefined reference to `dread_'
    R83ZAmacDBL.f:(.text+0x2541c): undefined reference to `dread_'
    collect2: error: ld returned 1 exit status
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/ccZHXd1f.o: In function `master.0.randu_':
    RANVAX.f:(.text+0xd8): undefined reference to `ran__'
    collect2: error: ld returned 1 exit status
    RANVAXxlf.f:26:25:
    
           CALL RANDOM_NUMBER(RANDU)
                             1
    Error: 'harvest' argument of 'random_number' intrinsic at (1) must be a variable
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/cczHKNeN.o: In function `master.0.forset_':
    RFRCmacDBL.f:(.text+0x6150): undefined reference to `datarefyear_'
    RFRCmacDBL.f:(.text+0x66e8): undefined reference to `datafiletrend_'
    collect2: error: ld returned 1 exit status
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    collect2: error: ld returned 1 exit status
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/ccHcb6ab.o: In function `clocks_':
    UTILwinDBL.f:(.text+0x10): undefined reference to `clock_'
    /tmp/ccHcb6ab.o: In function `timer_':
    UTILwinDBL.f:(.text+0x91c): undefined reference to `clock_'
    collect2: error: ld returned 1 exit status
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/ccedO0mK.o: In function `setpath_':
    setpath.f:(.text+0xc): undefined reference to `iargc__'
    setpath.f:(.text+0x34): undefined reference to `getarg__'
    setpath.f:(.text+0x44): undefined reference to `chdir__'
    collect2: error: ld returned 1 exit status
    

    None of it looks particularly horrible to me, just takes time to go through, one at a time, fixing what it doesn’t like.

  6. E.M.Smith says:

    I think this bit is the key to a lot of those errors:

    OS X GNU Fortran

    This platform is not officially supported. There is a Makefile.gfortran in the source directory which works at the time of this writing. You’ll need to edit RANVAX.f and setpath.f to remove some “_”‘s.

    So that’s where I’ll start on the debugging…. That, and making my own Makefile.Pi to drive it…

    The top level Makefile looks to drive the others, so just adding my own (based on the gfortran one) and a bit of ‘how to sense my computer type’ will likely do it.

    [root@ARCH_pi_64 trunk]# cat Makefile
    SVNVER=$(shell svn info | grep "Last Changed Rev" | cut -d" " -f4)
    TODAY=$(shell date +%Y%m%d)
    
    all:
    #	Encode version into GCM README outputs
    	sed s/cREV/\ \ \ \ \ \ \PRINT\ *,\ \'Revision\:\ ${SVNVER}\'/ README.f.in > README.f
    
    #	build model(s) for PPC and Intel
    	@echo " "
    	@echo " "
    	@echo "To build model, run the following commands:"
    	@echo " "
    	@echo "ifort.setup"
    	@echo "make -f Makefile.ifort clean; make -f Makefile.ifort "
    	@echo " "
    	@echo "absoft.ppc.setup"
    	@echo "make -f Makefile.Mac.PPC clean; make -f Makefile.Mac.PPC"
    	@echo " "
    	@echo "make install"
    	@echo " "
    
    install: 
    	cp modelII_intel.exe modelII_ppc.exe ../../../EdGCM/Applications/Model/
    
    clean:
    	rm -f *.o
    	rm -f model.command
    	rm -f modelII_intel.exe
    	rm -f modelII_ppc.exe
    

    So where it says do a Makefile.ifort or Makefile.Mac.PPC I’ll need to do something else…

    Well, time to get back to looking at programs ;-)

  7. E.M.Smith says:

    Interesting… the two .r files…

    * 	modelF.r
    *
    *
    *	Created on Thu Apr  8 20:33:43 2004
    *	Copyright (c) 1996 - 2004 All rights reserved.
    *	ABSOFT CORPORATION, Rochester Hills, Michigan 48309
    *	United States of America
    *
    ***********************************************************************
    *
    *   U.S. GOVERNMENT RESTRICTED RIGHTS. The software and
    *   documentation are provided with RESTRICTED RIGHTS. Use,
    *   duplication, or disclosure by the Government is subject
    *   to restrictions set forth in subparagraph (c)(1)(ii) of
    *   the Rights of Technical Data and Computer Software
    *   clause at 252.227-7013. The contractor/manufacturer is
    *   Absoft Corporation, 2781 Bond Street, Rochester Hills,
    *   Michigan 48309.
    *
    ***********************************************************************
    *
    *   PURPOSE OF FILE
    *
    *   Contains resource source code for the Macintosh Runtime Window
    *   Environment library. 
    

    So the Window Environment is likely going to be an issue if I want the GUI stuff. I’ll cross that when I must. I doubt the window interface is required by the base model.

    Similarly:

     * 	mrweprefs.r
     *
     *
     *	Created on Thu Apr  8 20:33:43 2004 for modelF
     *	Copyright (c) 2004 All rights reserved.
     *	ABSOFT CORPORATION, Rochester Hills, Michigan 48309
     *	United States of America
     *
     ******************************************************************************/
    
    #define DefaultFont      -1
    #define DefaultFontSize  -1
    #define DefaultLineSpace -1
    
    #define NoPauseAtEnd  -1
    #define PauseAtEnd     1
    

    One hopes there’s some easy way to get the same functions in X land…

    The one .sh file is trivial. A “one line script”:

    [root@ARCH_pi_64 trunk]# cat PostBuild.sh 
    
    	cp modelII.icns 'modelII\ 8x10x9.app/Contents/Resources/'
    

    So, with that, I’m down to the dozen FORTRAN program files and the 4 COMMON block bits of FORTRAN in files.

    OK, gui issues differed, Makefile issues easily tractable, the “libs” issues likely none by default.

    Time to dive into the FORTRAN files…

  8. E.M.Smith says:

    Starting with the smallest ones and working up… This is ‘setpath.f’ and is 36 lines of code…

    c  *********************************************************************
    c  *********************************************************************
    c  **
    c  ** setpath
    c  ** SetPath changes the cwd (current working directory) based on a 
    c  ** parameter passed in to the command line. In Unix the path can
    c  ** be anything but under Windoz it has to be a realtive path. This
    c  ** code works around a bug where AP ShellExecute in Windows sets the
    c  ** path to the database folder instead of the fortran program`s 
    c  ** folder.
    c  **
    c  ** CHANGE HISTORY:
    c  **
    c  ** 05/04/04 developed from GetArgs (MFS)
    c  ** 05/06/04 no error version so it can work on the Mac too (MFS)
    c  ** 05/07/04 model sepecific version with underscore (MFS)
    c  **
    c  ** NOTES:
    c  ** f77 -f -lU77 -N15 setpath.f
    c  **
    c  *********************************************************************
    c  *********************************************************************
    
          SUBROUTINE SETPATH
          INTEGER*4 ARGC             ! arg count
          CHARACTER*255 ARGV         ! arg values (path)
          INTEGER*4 IERR             ! path error
    
          ARGC = IARGC_()                         
          IF (ARGC .GE. 1) THEN
              CALL GETARG_(1,ARGV)    ! get path as arg
              IERR = CHDIR_(ARGV)     ! change working directory
          END IF
    
          END
    

    As it is a workaround for a Windoz bug / issue, likely can be coded out of a Pi version (or left in if it is a null impact).

    Next!

  9. E.M.Smith says:

    RANVAX.f is also short:

    [root@ARCH_pi_64 trunk]# cat RANVAX.f 
    c  *********************************************************************
    c  *********************************************************************
    c  **
    c  ** Model IImac
    c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
    c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
    c  ** Based on MP030BmacC9, BA94C9 and MA94DC9
    c  **
    c  ** CHANGE HISTORY:
    c  **
    c  ** 05/25/01 Linux needed new random number generator (JAJ)
    c  ** 09/28/02 to unify model use new style ran_ (MFS)
    c  ** 06/22/04 use old random function for xlf (MFS)
    c  ** 01/27/05 restored to old version (MFS)
    c  **
    c  ** NOTES:
    c  **
    c  *********************************************************************
    c  *********************************************************************
    
          FUNCTION RANDU (X)
          IMPLICIT REAL*8 (A-H,O-Z)
    c      REAL*4 ran
          RANDU=ran_(IX)
    C**** THIS FUNCTION GENERATES RANDOM NUMBERS ON AN IBM 360 OR 370
    C  10 IY=IX*65539
    C     IF (IY) 20,40,30
    C  20 IY=(IY+2147483647)+1
    C  30 IX=IY
    C     RANDU=DFLOAT(IY)*.465661287308D-9
          RETURN
    C  40 IX=1
    C     GO TO 10
          ENTRY RINIT (INIT)
          IX=INIT
          RINIT=0.0 
          RETURN
          ENTRY RFINAL (IFINAL)
          IFINAL=IX
          RFINAL=0.0 
          RETURN
          END
    

    IBM 360? Really? Man that bit of code has been kicking around a long time…

    [root@ARCH_pi_64 trunk]# gfortran RANVAX.f 
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    /tmp/ccGJZ6fT.o: In function `master.0.randu_':
    RANVAX.f:(.text+0xd8): undefined reference to `ran__'
    collect2: error: ld returned 1 exit status
    

    Copy it to a new name and edit out the suspect part:

    [root@ARCH_pi_64 trunk]# cp RANVAX.f ranvax.f
    [root@ARCH_pi_64 trunk]# vi ranvax.f

    I suspect the “issue” is that RANDU=ran_(IX) where the _ is likely wrong… taking out the underscore:

    [root@ARCH_pi_64 trunk]# gfortran ranvax.f
    /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.3.0/../../../crt1.o: In function `_start':
    init.c:(.text+0x34): undefined reference to `main'
    collect2: error: ld returned 1 exit status
    

    Oh Dear. Got past the ran_ error but now doesn’t like something in the gnueabihf library function _start and still fines an undefined reference to ‘main’

    I think I may need to show that the gfortran on this chip image works right before I go forward…

    Off to compile / test a couple of vanilla FORTRAN programs known to work, then come back to this and figure out ‘wha?’… Likely to be a while… as it’s getting late here and sleep will claim me soon ;-)

  10. E.M.Smith says:

    Well, my parallel FORTRAN tests compile and run, but this doesn’t. Using:
    gfortran -static-libgfortran setpath.f
    gives:

    /usr/bin/ld: cannot find -lgfortran
    collect2: error: ld returned 1 exit status
    

    Which I think says it got through the compile phase and into the link / loader phase before barfing on missing standard libraries.

    I think I may have a library issue. Easy test, try the same compile on a Debian chip where I’ve compiled all of GIStemp before (with LOTS of odd FORTRAN in it…)

    No sense spending time trying to debug the port if I don’t know the tool chain works on complicated things. That random generator code is pretty simple, so I’m suspecting the Arch Linux FORTRAN isn’t quite right (or my calling sequence is way off somehow… those default libraries in the set up script).

    In any case, it’s late and I’m taking a break on this until tomorrow…

  11. E.M.Smith says:

    Oh that “one last thing” moment… I was about to log out and noticed the two RANVAX* seemed awfully similarly named:

    sh-4.3$ diff RANVAX.f RANVAXxlf.f 
    14a15,16
    > c  ** 04/26/05 use xlf version from lr p 509 (MFS)
    > c  ** 04/29/05 xlf version, different random (MFS)
    24c26
           CALL RANDOM_NUMBER(RANDU)
    34a37,38
    >       RINIT_H = INIT
    >       CALL RANDOM_NUMBER(HARVEST = RINIT_H)
    sh-4.3$ gfortran RANVAXxlf.f 
    RANVAXxlf.f:26:25:
    
           CALL RANDOM_NUMBER(RANDU)
                             1
    Error: 'harvest' argument of 'random_number' intrinsic at (1) must be a variable
    

    OK, with the “CALL RANDOM” it compiles without the strange C like error messages, but with a complaint about one of the arguments. Does that mean it would compile completely if that argument issue were resolved, or just that it would THEN reach that old error message state. Don’t know right now, but it is an interesting difference.

  12. pearce m. schaudies says:

    Hi Chief. when making first debug runs you might make the grid size 16 by 20 degrees instead of 8 by 10. Then it might run twice as fast haha.
    x

  13. E.M.Smith says:

    8 x 10 = 80

    16 × 20 = 320

    That’s 1/4 the cells for the same area, so it ought to be 4 x as fast…

    But first I need it to run at all…

  14. p.g.sharrow says:

    check your pub4all and see if the test works. your donation link is outdated…pg

  15. E.M.Smith says:

    @P.G.: OK.

    @All:

    Well, I got it to compile most of the stuff. I figured perhaps ‘main’ was missing as it was somewhere built by the Makefile. I copied the Makefile.gfortran to Makefile.pi and commented out the ‘LIBS’ line. It worked all the way down to a make of “README.o” where “README.f” was missing (as there isn’t one…) so I need to look at the top level Makefile (that I think makes it from README.f.in) and do that step first.

    The Makefile.pi as it stands now:

    pi@raspberrypi:/GCM $ cat Makefile.pi
    
    F77COMPILER= gfortran
    LINKER =    gfortran
    F77_FLAGS =   -c -s -fconvert=big-endian -fno-automatic -ff2c -O2
    # ifort  -O2   -convert big_endian       -IPF_fma  -save  -zero  -ftz  -assume 
    # dummy_aliases  -align none -mp      -openmp   -c L23_DAILY_MClim_CH4mths.f  
    
    #LIBS = -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
    TARGET=      model.command
    
    SRCS = RANVAX.f \
    	setpath.f \
    	RFRCmacDBL.f \
    	UTILmacDBL.f \
    	Mjal2cpdC9.f \
    	Pjal0C9.f \
    	FORCINGSjalC9.f \
    	FFT36macDBL.f \
    	R83ZAmacDBL.f \
    	DB11pdC9.f \
    	README.f
    OBJS = $(SRCS:.f=.o)           # all objects
    
    %.o: %.f
    	$(F77COMPILER) -o $@ $(F77_FLAGS) $<
    
    $(TARGET): $(OBJS)
    	$(LINKER) $(LPATHS) $(OBJS) $(LNK_FLAGS) $(LIBS) -o $(TARGET)
    
    clean:
    	rm -f *.o
    	rm -f $(TARGET)
    
    .PHONEY: all clean
    

    This was done on a generic Debian Jessie, but I don’t think that matters. As this browser is being a pain (crashing) I’m likely to not use this system for the rest ;-)

  16. E.M.Smith says:

    Here’s a listing for the directory at the moment. You can see the .o files it made as output (and that .tarx is my format for moving things around in a compressed tarball…)

    pi@raspberrypi:/GCM $ ls -l
    total 2736
    -rw-r--r-- 1 pi pi   3926 Aug  2  2005 B83XXDBL.COM
    -rw-r--r-- 1 pi pi   3164 Aug  2  2005 BA94jalC9.COM
    -rw-r--r-- 1 pi pi   5548 Jan 17  2006 commandlinetest.gui
    -rw-r--r-- 1 pi pi 240095 Apr 17  2008 DB11pdC9.f
    -rw-r--r-- 1 pi pi 254068 Dec 27 14:26 DB11pdC9.o
    -rw-r--r-- 1 pi pi  13208 Aug  2  2005 FFT36macDBL.f
    -rw-r--r-- 1 pi pi  14944 Dec 27 14:25 FFT36macDBL.o
    -rw-r--r-- 1 pi pi   5362 Aug  2  2005 FORCINGSjalC9.f
    -rw-r--r-- 1 pi pi   3516 Dec 27 14:25 FORCINGSjalC9.o
    -rw-r--r-- 1 pi pi   1333 Aug  2  2005 FORCINGSmac.COM
    -rw-r--r-- 1 pi pi    876 Mar 23  2006 Info.plist
    -rw-r--r-- 1 pi pi    755 Apr 17  2008 Makefile
    -rw-r--r-- 1 pi pi    747 Apr  1  2008 Makefile.gfortran
    -rw-r--r-- 1 pi pi    706 May 12  2008 Makefile.ifort
    -rw-r--r-- 1 pi pi    612 May 12  2008 Makefile.Mac.PPC
    -rw-r--r-- 1 pi pi    748 Dec 27 14:24 Makefile.pi
    -rw-r--r-- 1 pi pi   3145 Apr 18  2008 Makefile.README
    -rw-r--r-- 1 pi pi   9238 Apr 17  2008 Makefile.win
    -rw-r--r-- 1 pi pi   2252 Apr 17  2008 Makefile.win.gui
    -rw-r--r-- 1 pi pi 204365 Mar 23  2006 Mjal2cpdC9.f
    -rw-r--r-- 1 pi pi 124372 Dec 27 14:25 Mjal2cpdC9.o
    -rw-r--r-- 1 pi pi  11887 Aug  2  2005 modelF.r
    -rw-r--r-- 1 pi pi 300600 Dec 27 14:06 ModelII.tarx
    -rw-r--r-- 1 pi pi   1475 Aug  2  2005 mrweprefs.r
    -rw-r--r-- 1 pi pi    132 Aug  2  2005 pd_COMMON
    -rw-r--r-- 1 pi pi 331692 Jan 17  2006 Pjal0C9.f
    -rw-r--r-- 1 pi pi 126744 Dec 27 14:25 Pjal0C9.o
    -rw-r--r-- 1 pi pi     59 Aug  2  2005 PostBuild.sh
    -rw-r--r-- 1 pi pi 555793 Aug  2  2005 R83ZAmacDBL.f
    -rw-r--r-- 1 pi pi 280856 Dec 27 14:25 R83ZAmacDBL.o
    -rw-r--r-- 1 pi pi   1248 Dec 27 04:35 ranvax.f
    -rw-r--r-- 1 pi pi   1249 Aug  2  2005 RANVAX.f
    -rw-r--r-- 1 pi pi   1168 Dec 27 14:24 RANVAX.o
    -rw-r--r-- 1 pi pi   1426 Dec 27 05:13 ranvaxxlf.f
    -rw-r--r-- 1 pi pi   1427 Aug  2  2005 RANVAXxlf.f
    -rw-r--r-- 1 pi pi   3339 Mar 13  2007 README.f.in
    -rw-r--r-- 1 pi pi 128314 Aug  2  2005 RFRCmacDBL.f
    -rw-r--r-- 1 pi pi  41560 Dec 27 14:24 RFRCmacDBL.o
    -rw-r--r-- 1 pi pi   1324 Jan 17  2006 setpath.f
    -rw-r--r-- 1 pi pi   1232 Dec 27 14:24 setpath.o
    -rw-r--r-- 1 pi pi   4203 Jan 18  2006 UTILmacDBL.f
    -rw-r--r-- 1 pi pi   4184 Dec 27 14:24 UTILmacDBL.o
    -rw-r--r-- 1 pi pi   4202 Dec 14  2006 UTILwinDBL.f
    pi@raspberrypi:/GCM $ 
    

    So some substantial progress. Looks like mostly I need to just clean up the Makefiles for it all to work on the Pi, then test the final result. “We’ll see”…

  17. E.M.Smith says:

    OK, the top Makefile has this in it:

    root@raspberrypi:/GCM# cat Makefile
    
    SVNVER=$(shell svn info | grep "Last Changed Rev" | cut -d" " -f4)
    TODAY=$(shell date +%Y%m%d)
    
    all:
    #	Encode version into GCM README outputs
    	sed s/cREV/\ \ \ \ \ \ \PRINT\ *,\ \'Revision\:\ ${SVNVER}\'/ README.f.in > README.f
    

    You can see that last line makes the README.f file from README.f.in via stuffing in the subversion (SVN) release number. This pi doesn’t have svn installed, so errors on that call to the shell to set SVNVER. I’m not interested in installing svn, so I’m just going to hardcode that to 0.0 and “move on”. Having a makefile just to do that svn version setting is kinda silly anyway… The key bit is to make the README.f file that contains, basically, version header info to be stuffed into things later…

    pi@raspberrypi:/GCM $ cat README.f
    c  *********************************************************************
    c  *********************************************************************
    c  **
    c  ** Model IImac
    c  ** Based on GCMII code for IBM RS/6000 computers created at GISS
    c  ** Modified to compile under Absoft Pro Fortran 6.2 for MacOS.  
    c  ** Based on MP008macC9, BA94C9 and MA94DC9
    c  **
    c  ** CHANGE HISTORY:
    c  **
    c  ** 12/26/00 first official readme file (MFS)
    c  ** 01/02/01 updated readme (MFS)
    c  ** ...
    c  ** 01/25/01 roman from http://www.schnoggo.com/figlet.html (MFS)
    c  ** 02/10/01 revised readme format (MFS)
    c  ** ...
    c  ** 04/08/04 changed font (JAL)
    c  ** 04/09/04 redesigned readme (MFS)
    c  ** 04/12/04 updated readme (MFS)
    c  ** ...
    c  ** 05/06/04 alternate PC version (MFS)
    c  ** 05/07/04 updated readme (MFS)
    c  ** ...
    c  ** 07/22/05 changes for command line (MFS)
    c  ** 07/28/05 updated readme (MFS)
    c  ** 08/02/05 revised for subversion (MFS)
    c  ** 10/17/05 updated readme (MFS)
    c  ** 12/19/05 updated readme (MFS)
    c  ** 01/17/06 updated readme (MFS)
    c  ** 03/23/06 updated readme (MFS)
    c  **
    c  ** NOTES:
    c  ** Many of the comments about the code can be found either in the
    c  ** source files or in svn.
    c  **
    c  *********************************************************************
    c  *********************************************************************
    
    c  ** Print out the initial text in the MWRE window.
          SUBROUTINE readme
          PRINT *, ' EEEEEEEEEEE       ddd    .GGGGGG.      .CCCCCC.   MMM',
         *  '        MMMMM '
          PRINT *, ' EEE       |       ddd   GGG''  `GGG    CCC''  `cCC  ',
         *  '`MM.       .MMM'''
          PRINT *, ' EEE          .ddddddd  GGG           CCC           MM',
         *  'MM     M''MMM  '
          PRINT *, ' EEEEEEEE    ddd'' `ddd  GGG           CCC           M',
         *  ' MMM. .M  MMM  '
          PRINT *, ' EEE         dd     dd  GGG     gGGGG CCC           M ',
         *  ' `MMM''   MMM  '
          PRINT *, ' EEE       | ddd   ddd  `GG.    .GG''  `CCC    cCC   M',
         *  '    V     MMM  '
          PRINT *, ' EEEEEEEEEEE `dddddddd   `GGGGGGGG''    `CCCCCCCC''  M',
         *  'MM        MMMMM '
          PRINT *, '                                                      '
          PRINT *, 'Model: Model II (8x10x9)                              '
          PRINT *, 'Revision: '
    cDAT
          PRINT *, 'Platform: MacOS X 10.3.9-10.4/Windows 2000/XP/Vista   '
          PRINT *, 'Contact: Mark Chandler, mac59@columbia.edu            '
          PRINT *, '         Ken Mankoff, mankoff@giss.nasa.gov           '
          PRINT *, '                                                      '
          END
    
    c  ** print out more info into the window and set the window
    c  ** title using Mac specific code (no other way)      
          SUBROUTINE readme2 (runnumber,geomname)
          CHARACTER*21 runnumber, RUNSHORT
          CHARACTER*8 geomname
          INTEGER LLAB1
          LLAB1 = INDEX(runnumber,'(') -1
          RUNSHORT = runnumber(1:LLAB1)
    C      PRINT *, 'Geometry: ',TRIM(geomname)
          PRINT *, 'Screen output (this window) saved to: "',TRIM(RUNSHORT),
         *   '" output folder'
          PRINT *, 'Accumulated diagnostics: "acc" folder                 '
          PRINT *, 'Restart files saved to: "rsf" folder                  '
          PRINT *, 'Monthly diagnostic printouts saved to: "prt" folder   '
          PRINT *, '                                                      '
          END
    

    So, ok, patching around their ‘too clever by 1/2’ version setting and odd use of README… and “moving on”…

  18. E.M.Smith says:

    In “Makefile” I changed to this:

    root@raspberrypi:/GCM# cat Makefile
    
    #SVNVER=$(shell svn info | grep "Last Changed Rev" | cut -d" " -f4)
    SVNVER=0.0
    

    forcing the svn version number to 0.0 until such time as I decide what to do about it…

    then the Makefile runs (just making README.f and advising what to do next):

    root@raspberrypi:/GCM# make
    sed s/cREV/\ \ \ \ \ \ \PRINT\ *,\ \'Revision\:\ 0.0\'/ README.f.in > README.f
     
     
    To build model, run the following commands:
     
    ifort.setup
    make -f Makefile.ifort clean; make -f Makefile.ifort 
     
    absoft.ppc.setup
    make -f Makefile.Mac.PPC clean; make -f Makefile.Mac.PPC
     
    make install
    

    For me, it will be “make -f Makefile.pi” and I’m not bothering with the ‘make clean’ as I’m just getting things to compile…

  19. E.M.Smith says:

    Looks like I’m up to that “deal with the ‘_’ problem” it advised about:

    root@raspberrypi:/GCM# make -f Makefile.pi
    gfortran -o README.o -c -s -fconvert=big-endian -fno-automatic -ff2c -O2 README.f
    gfortran  RANVAX.o setpath.o RFRCmacDBL.o UTILmacDBL.o Mjal2cpdC9.o Pjal0C9.o FORCINGSjalC9.o FFT36macDBL.o R83ZAmacDBL.o DB11pdC9.o README.o              -o model.command
    RANVAX.o: In function `randu_':
    RANVAX.f:(.text+0x4): undefined reference to `ran___'
    setpath.o: In function `setpath_':
    setpath.f:(.text+0x4): undefined reference to `iargc___'
    setpath.f:(.text+0x24): undefined reference to `getarg___'
    setpath.f:(.text+0x30): undefined reference to `chdir___'
    collect2: error: ld returned 1 exit status
    Makefile.pi:28: recipe for target 'model.command' failed
    make: *** [model.command] Error 1
    

    So it found all the .o object files (including the now extant README.o) and tried to link them all. At that point, the FUNCTION_ stuff started to stack up. OK, I can work with that. It had, earlier, said that would pop up. Essentially up to now has been fixing the Makefile settings and getting compiler flags and such set right. Now I can start the actual porting / debugging of the model code. That, then, sends me back to the advisory about gfortran not liking the underscores and where I need to change them… so that’s where I’m off to next.

  20. E.M.Smith says:

    Removing the underscores (as it advised for gfortran) from the function calls in setpath.f and RANDVAX.f results in:

    root@raspberrypi:/GCM# make -f Makefile.pi 
    gfortran -o RANVAX.o -c -s -fconvert=big-endian -fno-automatic -ff2c -O2 RANVAX.f
    gfortran -o setpath.o -c -s -fconvert=big-endian -fno-automatic -ff2c -O2 setpath.f
    gfortran  RANVAX.o setpath.o RFRCmacDBL.o UTILmacDBL.o Mjal2cpdC9.o Pjal0C9.o FORCINGSjalC9.o FFT36macDBL.o R83ZAmacDBL.o DB11pdC9.o README.o              -o model.command
    

    What looks like a successful compile and link.

    root@raspberrypi:/GCM# ls -l model.command 
    -rwxr-xr-x 1 root root 780300 Dec 27 15:06 model.command
    root@raspberrypi:/GCM# file model.command 
    model.command: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=b65a34b85ac237367895de75c82a200459e4b6ae, not stripped
    

    Guess it’s on to first cut testing ;-)

    Here’s the modifications to the two programs:

    root@raspberrypi:/GCM# diff OLD_setpath.f setpath.f 
    29c29
           ARGC = IARGC()                         
    31,32c31,32
    <           CALL GETARG_(1,ARGV)    ! get path as arg
               CALL GETARG(1,ARGV)    ! get path as arg
    >           IERR = CHDIR(ARGV)     ! change working directory
    
    root@raspberrypi:/GCM# diff OLD_RANVAX.f RANVAX.f
    24c24
           RANDU=ran(IX)
    
  21. E.M.Smith says:

    Well, it looks like I may get to make a bunch of input files by hand. I’ve got some more poking around to do to see if there is a default set somewhere, but for now this is what I’ve found:
    http://edgcm.columbia.edu/ModelII/InputFiles.html

    This document covers:
    Format of input files
    Contents of input files
    Mapping between files and unit numbers used by the model
    To learn about relationship and rules between input files, see GCM/InputFileRules
    
    The format for this document is:
    
    Unit: ###
    Name: 
    Ex: 
    Size: xx kb or xx bytes
    Description: 
    Arrays: 
    Initial Conditions
    
    Ground Data
    
    Unit: 7
    Name: Ground Data
    Ex: G8X10
    Size: 48392 bytes
    Description: This file is used for istart=5 runs, paleo runs where the ground data does not match the information in the atmospheric conditions file because the ground has moved.
    Arrays: GS(IM*JM*14) which is described as
    snow amount for ocean ice (kg h2o/m**2)
    snow amount for earth (kg h2o/m**2)
    first ground temperature for ocean ice (deg c)
    first ground temperature for earth (deg c)
    first ground earth water (kg h2o/m**2)
    first ground earth ice (kg h2o/m**2)
    second ground temperature for ocean ice (deg c)
    second ground temperature for earth (deg c)
    second ground earth water (kg h2o/m**2)
    second ground earth ice (kg h2o/m**2)
    age of snow (days)
    snow amount for land ice (kg h2o/m**2)
    first ground temperature for land ice (deg c)
    second ground temperature for land ice (deg c)
    Restart File
    
    Unit: 9/109
    Name: Atmospheric initial conditions, also known as the restart file (rsf)
    Ex: NOV1910.rsfP003a
    Size: 473,364-715,284 bytes (qflux or sst vs deep ocean)
    Description: All the information about the atmosphere of a run is saved into this file. As the model runs a restart file is generated every month which can be used to also start new runs. Many utilities can modify this file to change the initial conditions for a run. The first and last values in the file are the TAU the file was saved at and can be used as a safety check.
    Arrays: The varied size is because some arrays are required and some are optional. The required arrays are:
    TAU,JC,C,RC,KEYNR,U,V,T,P,Q,ODATA,GDATA,BLDATA,RQT,SRHR,TRHR,TSFREZ
    The optional arrays for deep ocean runs are:
    TG3M,RTGO,STG3,DTG3
    At the end of the file is always another:
    TAU
    Ocean
    
    Unit: 15
    Name: Ocean
    Ex: O8X10, O8X10.100MLD
    Size: 124,560 bytes (3 array), 166,032 bytes (4 array), 16,579,248 bytes (observed)
    Description: There are three versions of this file. The smaller ocean file has just the surface temperatures for the ocean for every month. When the smaller file is used the ocean temperature is fixed. The larger 4 array ocean file adds in a mixed layer depth so that the water in the mixed layer can change temperature. For the mixed layer to work some additional files must be read in by the model. The third version of the file is observed mode. The ocean file contains a number of years of ocean data starting from February of the first year. TAUI is matched to the start of the first year of the ocean file so that the model can advanced the file to the correct month. In all cases the ocean files contain an averaged value for the middle of each month and days are linearly interpolated between the two nearest monthly values
    Arrays: Two version of the ocean include 12 months of data with the following format for the 3 array ocean:
    MON, O(IM,JM,3)
    The 4 array ocean adds a mixed layer depth:
    MON, O(IM,JM,3), OMLD(IM,JM)
    Arrays: Observed oceans contain these arrays repeated from 02/01/1870-12/01/1998
    The contents of the (IM,JM,3) array is
    
       1. OCEAN SURFACE TEMPERATURE (DEGREES C)'
       2. RATIO OF OCEAN ICE TO WATER (PERCENT)',
       3. OCEAN ICE AMOUNT OF LAYER 2 (10**2 KG/M**2)',
    And the 4th layer is the mixed layer depth.
    
    The format of the observed ocean file is (thanks to vieira):
    
    I read the O8X10.B.1871.M02.Hadl1.1.obsr data file 
    successfully. I have used the following format:
    
    • FORTRAN format (header/trailer for each record)
    • Register number: integer 32 bits
    • Data (36x24x3): 4 byte floating point
    • Year: 32 bits integer
    • Month: 32 bits integer
    Ocean Transports
    
    Unit: 17
    Name: Ocean transports spectral coefficient (OTSpec)
    Ex: OTSPEC.RP041bC9.M250ZD
    Size: 62,216 bytes
    Description: fourth order spectral coefficients for ocean heat transports in the qflux and deep ocean. Gary developed a complex scheme where the annual temperature variations of an ocean grid cell's mixed layer are encoded into spectral coefficients. The upshot is that the otspec file adjusts the temperature of the mixed layer to incorporate season and the energy that would be added or removed by ocean currents (if they existed).
    Arrays:
    OTA1(IM,JM),OTB1(IM,JM),OTC(IM,JM)   
    OTA2(IM,JM),OTB2(IM,JM),OTA3(IM,JM) 
    OTB3(IM,JM),OTA4(IM,JM),OTB4(IM,JM)
    Drag Coefficient
    
    Unit: 19
    Name: Drag coefficient
    Ex: CD8X10
    Size: 3464 bytes
    Description: Drag coefficient
    Arrays: ROUGHL(IM,JM)
    Radiation
    
    Unit: 21
    Name: Radiation RTAU
    Ex: RTAU.G25L15
    Size: 316 kb
    Description: Radiation RTAU
    Arrays: ?
    Radiation
    
    Unit: 22
    Name: Radiation RPLK
    Ex: RPLK25
    Size: 28 kb
    Description: Radiation RPLK
    Arrays: ?
    Vegetation
    
    Unit 23
    Name: Vegetation
    Ex: V8X10
    Size: 28040 bytes
    Description: There are eight types of vegetation defined by the model. Eight arrays store the distributions of vegetation as a percentage of the land in each grid box. There is also a veg-table (vadata) that defines the properties of each of the kinds of vegetation. The four (!) sections of the veg-table are: bare earth visual albedos (seasonal), bare earth near ir albedos (seasonal), water field capacities in kg/m**2 (3 arrays), masking depths in m (1 array). Since the eight simple types are mappings from thirty complex types the distributions are difficult to change for the modern. See NASA tech memo 86096, June 1984, Elaine Matthews.
    Arrays: V(IM,JM,8), VADATA(8,4,3)
    The order of the vegetation in the file is:
    
         1'RATIO OF DESERT TO EARTH (PERCENT)',
         2'RATIO OF TUNDRA TO EARTH (PERCENT)',
         3'RATIO OF GRASSLAND TO EARTH (PERCENT)',
         4'RATIO OF SHRUB/GRASSLAND TO EARTH (PERCENT)',
         5'RATIO OF TREE/GRASSLAND TO EARTH (PERCENT)',
         6'RATIO OF DECIDUOUS FOREST TO EARTH (PERCENT)',
         7'RATIO OF EVERGREEN FOREST TO EARTH (PERCENT)',
         8'RATIO OF RAINFOREST TO EARTH (PERCENT)'/
    QFlux Max Mixed Layer Depth
    
    Unit: 25
    Name: QFLUX Max Mixed Layer Depth
    Ex: Z1OMAX.8X10.250M
    Size: 3464 bytes
    Description: The mixed layer is the surface part of the ocean handled in qflux runs. The max mixed layer depth is simply the maximum thickness of the mixed layer during the year for every grid point. This array is trivial to calculate and later versions of the GCM do this internally instead of using this file. For not very good reasons this file usually starts with a Z however it is not connected to topography in any way.
    Arrays: (IM,JM)
    Topography
    
    Unit: 26
    Name: Topography
    Ex: Z8X101
    Size: 10376 bytes
    Description: The topography file defines the three inorganic properties of land in Model II. It is important to realize that this file is not the same as in Model II' or Model E. The three properties are: topographic height in meters scaled by gravity, land cover, and land ice. The topographic height is the area weighted average height of the land in a grid box. The wacky part is that topographic height is scaled by gravity. Land cover is just the percent of a grid box covered by land. Land ice is the percentage of land in a grid box covered by ice. Thus is a grid box is 12% land by all that land is ice covered then the land ice is 100%. Land ice is special unmelting ice that doesn't interact with the ice created by repeated snowfall.
    Arrays: PHIS(IM,JM),PLAND(IM,JM),RLICE(IM,JM)
    23 Special Regions
    
    Unit: 29
    Name: 23 special regions
    Ex: REG8X10
    Size: 3728 bytes
    Description: The 23 special regions in model have extra information collected for them. Unlike all the other input files there is a hidden special regions file in the model that is used if no file is read in. The file contains an 80 byte title and then a single array of the 23 special regions. The regions are numbered 1-23 with 24 as no special region. Since there is only a single array the regions cannot overlap, but they do not have to be contiguous. The last array contains the names of the 23 special regions as 8 character strings.
    Arrays: TITLE, JREG(IM,JM), IXJX(23)
    Deep Ocean
    
    Unit: 62
    Name: ED Deep Ocean
    Ex: ED8X10
    Size: 3464 bytes
    Description: Eddie diffusions to the deep ocean from modern observations. How fast the bottom of the mixed layer is diffused into the deep ocean. This file is only used when kocean=2.
    Arrays: EDO(IM,JM)
    

    Many of them are only used with particular settings, so I might be able to make a minimal subset that lets me find out if the model runs at all.

    This is likely to keep me busy for a while… “we’ll see”…

  22. E.M.Smith says:

    Nice to know that if you don’t get the input files just so the model crashes… bolding mine.

    This document is a work in progress.
    This document describes the rules and relationships between input files. If these rules are not obeyed, the model will crash. For details about a given input file, see GCM/InputFiles.

    Every grid cell with any ocean must have ocean temperatures set
    Ocean temperatures should not be below -1.8 C
    Every grid cell that has exposed ground (not ocean or land ice) must have vegetation
    The sum of the eight vegitation types must be 100% for any grid cell with exposed ground
    Cells with snow or ice cover should have frozen ground
    Cells without snow or ice cover should not have frozen ground
    Land ice is part of the topography file so the height of the land ice is included in the topographic height of a cell

    from: http://edgcm.columbia.edu/ModelII/InputFileRules.html

  23. E.M.Smith says:

    Well, working down their list of documentation postings… this one is more interesting than I’d expected:

    http://edgcm.columbia.edu/ModelII/NameList.html

    It contains some cryptic hints about how to do the initial startup:

    ISTART, way to start/restart the model:
    
      1-9 (except 4) - initial starts
      4,9-infinity   - restarts
    
      1=start from uniform conditions
      2=start from observed conditions
      3=start from end-of-month restart file(rsf) of some previous run
              whose rsf matches the rsf of the current run
      5-9=start from end-of-month rsf of some previous run whose rsf is
              structured differently (missing arrays etc), often INPUT
              has to be changed appropriately
      4=restart from own end-of-month rsf (in order to rerun a period 
        or to extend the run after fort.1/fort.2 are no longer present);
        occasionally ISTART=4 is also used to start a variation of a run to
        minimize the differences between the orig. run and the variation;
        sometimes TAUI is reset to the TAU at the start of the variation
        which defeats that purpose unless the new TAUI differs from the
        orig. TAUI by a multiple of 5, e.g. if it starts at the same day
        of the year as the original run, then there is no problem.
      10=restart from later of the rsfs fort.1 fort.2           (default)
      11=restart from fort.1
      12=restart from fort.2
      13-??=restart from earlier of the rsfs fort.1 fort.2
    

    But more interesting is some of the things in the model that might be available to play with. Like planetary parameters:

    RADIUS, radius of planet in meters (defaults to Earth), 6375000

    GRAV, gravity of planet in meters/second2 (defaults to Earth), 9.81

    RGAS, gas constant of planet. Despite the word constant the gas constant varies from planet to planet, 287

    KAPA, ratio of two quantities, .286

    o*OMEGA, is angular velocity of planet around its axis. OMEGA only for output purposes (see DLAT remarks) (setting it has no effect since it is recomputed), TWOPI*(EDPERD+EDPERY)/(EDPERD*EDPERY*SDAY)

    CCMCX, tunes moist convective cloud cover. It is used in model II but not in Yao’s newer schemes, 50000

    *ETA, should not be in namelist. Used in RFRC but reset to 1.5, 0

    S0X, solar flux value is 1367 W/m2. You can set the trend information for S0X in the FORCINGS namelist, 1367

    CO2, CO2 is 315 ppm. You can set the trend information for CO2 in the FORCINGS namelist. In old versions of the code negative values triggered trends, 315

    SRCOR, solar correction factor for qflux and deep ocean runs. Gone from model e because Jim doesn’t like it,

    Oh Really?… “Jim” (one presumes Hanson?) doesn’t “like” a solar correction factor…

    Interesting….

  24. E.M.Smith says:

    Oh, here’s a nice bit (same file) where it lists the ‘forcings’, or what control knobs the code presumes drives the globe:

    forcings

    This is the new forcings namelist to standardize how all the radiative forcings are handled by the model. This namelist supersedes the old ktrend code that was in RFRC. Unlike the old ktrend code each forcing is independent so there is a long list of settings.

    KTRENDEXT, trend to use in the model. 1 is the new style data trend. 2-5 are the classic Jim Hansen trend (a trend , b trend, c trend, d trend, y trend, z trend). A trend is inaccessible because 1 has been reused for the new trend. Negative numbers deactive trends, -1

    There are 2 kinds of forcing functions:

    Constant, use the initial value of the variable times the 1958 reference value

    Data, read values from a data file. The model will use the constant value for the gas before the data trend starts. After the last year in the data file the model will continue to use the last value in the file.

    There are seven different kinds of forcings. Each forcing has a default 1958 value that will be used if nothing is specified. The units for the forcings are in scaled model units, which are ppm for the gases, but in ?? for the sun:

    CO2, carbon dioxide primary greenhouse gas, 315

    ZN2O, Nitrous oxide, 0.295

    CH4, Methane, another greenhouse gas, mm yummy cows, 1.400

    F11, Stratospheric aerosols, 8.00E-6

    F12, Stratospheric aerosols, 25.0E-6

    S0X, Solar radiance, fractional increase or decrease of luminosity

    Since each forcing is similar I will document the forcing for CO2:

    CO2, constant value for CO2 in ppm, the 1958 value for CO2 is 315 ppm. Both CO2 and S0X are set in inputz and only the trend information is in forcings, 315

    CO2DATA, data file to read in years from. 0 means no data file, otherwise the number is the unit number of the fortran file to open. The files are formatted text files with the year and scaled data on each line. The code will automatically synchronize the file with the model year, 0

    CO2DATASTART, year to start reading data file, -1

    CO2DATAEND, year to stop reading data file, when the file runs out the model stops, -1

    So it has a solar constant in it, and is set up to accept change over time ( I think) if you load that into a file. I’d want to divide things into UV vs visible vs IR, but hey, all things in their proper order… first get it to run at all…

    Everything else is a diddle factor based on the Greenhouse Gas Thesis… so if the “solar constant” is kept constant, or only varies a tiny bit, then you MUST have the GHG effect to ‘tune’ the model to historical knowns…. Thus the cycle of belief begins… OK, so once this thing is running, my first thing to do is beef up the solar stuff, then add UV variation by altitude… but not, I think, today….

  25. E.M.Smith says:

    Gee… another interesting bit:

    http://edgcm.columbia.edu/ModelII/About.html

    Sea surface temperatures (SST) are either specified from climatological input files or may be calculated using model-derived surface energy fluxes and specified ocean heat transports. The ocean heat transports vary both seasonally and regionally, but are otherwise fixed, and do not adjust to forcing changes. This mixed-layer ocean model was developed for use with the GISS GCM and is often referred to as the “Qflux” parameterization. Full details of the Qflux scheme are described in Russell et al. (1985), and in appendix A of Hansen et al. (1997). In brief, the convergence (divergence) at each grid cell is calculated based on the heat storage capacity of the surface oce

    So the ocean has a seasonal swing to it, and has a little regional variation, but things like, oh, the Thermohaline Circulation and the Gulf Stream shifting overall global ocean heat are not going to change in response to either the sun or the gas ‘forcings’… Interesting. That thing which, IMHO, is MOST likely to be critically important to a Little Ice Age in Europe, or the onset of a global Ice Age Glacial, or even sporadic warming when it goes the other way, doesn’t change…

  26. E.M.Smith says:

    OK, I think that’s enough progress for one morning. I suppose that, now that I’ve got it compiled and found some interesting bits, it’s time to “RTFM”… Read The (ah….) Friendly Manual…

    They have a load of docs at:

    http://edgcm.columbia.edu/support2/documentation/

    Documentation
    Following are a variety of useful documents to help you with EdGCM. There are technical manuals, including the popular EdGCM Quick Start Guide, the full EdGCM Manual, and the manual to the EdGCM visualization application (EVA). See also our Supplemental Materials page for a copy of our professional development workshop guide, and some sample exercises.

    pdficon_small.gif EdGCM Quick Start Guide (4.9 MB PDF)

    pdficon_small.gif EdGCM Manual (7.1 MB PDF)

    pdficon_small.gif EVA Manual (2.6 MB PDF)

    pdficon_small.gif Hansen et al., 1983 original reference for GISS Model II (4.3 MB PDF)

    pdficon_small.gif How to set trends in EdGCM (245 kB PDF)

    For installation help, please see:

    pdficon_small.gif Notes for EdGCM 4.0 installation for Mac OS X 10.8 and higher (89 kB PDF)

    See also:

    EdGCM Video Tutorials

    EdGCM Frequently Asked Questions

    EdGCM Workshop Guide and Sample EdGCM Exercise on Global Warming

    pdficon_small.gif Earth Exploration Toolbook Teaching Materials for EdGCM (6.5MB PDF)

    For help with EzGCM, please see:

    pdficon_small.gif Getting Started With EzGCM (128 kB PDF)

    pdficon_small.gif MyGCM in EzGCM (388 kB PDF)

    And I suspect it will take me more than a day or two to wade through them all…

    With that, I’m “checking out” from the model porting business for the next good while while I curl up with a tablet, a cup-a, and some model operations PDFs to read…

  27. Sandy McClintock says:

    ” FUNCTION RANDU (X)
    IBM 360? Really? Man that bit of code has been kicking around a long time…”

    I had to smile!
    My first program, in 1968, used RANDU (on a 360) for simulating ‘genetic drift’ in small isolated breeding populations. (U for uniform RANDom numbers between 0 and 1)

    Good luck with the simulations – it keeps the brain well exercised!
    Have you read this claim? http://www.coolingnews.com/enso-ann
    If true would it be worth incorporating when you run out of things to do? ;)

  28. pearce m. schaudies says:

    Hi Chief. This PDF link says how GCMs are setup to magnify co2 effect. From ocean cooling post by win most at WUWT. … if you need to take an off topic break, heh.

    Click to access gray2010_heartland.pdf

  29. E.M.Smith says:

    @Sandy:

    I think it was still arround in 1973? when I learned FORTRAN IV …

    I’ll read the link in a moment…

    @Pearce:

    Yeah, a break would be nice.. just finished a cursory scan of the source code…

    @All:

    I’ve finished the docs and a rough scan of the source code. THE thing that stands out most is just how stongly the model is tuned to make CO2 causal.

    The docs mostly cover the edu GCM parts, that are the GUI for controlling input and doing graphical displays (and NOT included in the model source code…). There is a Hanson paper there (from 1987?) that does explain the operation. That paper also describes various sensitivities found in different runs. Essentially, lots of things get tailored to show just the right results HOLDING SUN CONSTANT and ASSUMING CO2 has a given effect. I’ll be doing a specific posting on that paper.

    THE biggest headache at the moment is those huge input parameter files. They are NOT included with the model source, but burried in the eduGCM part (separate download, at a price to keep it, and with licence entanglements). So I need to accept those handcuffs, or recreate the input files (to which the model is very sensitive and which need careful tuning…)

    So time to step aside for a while and let it simmer….

  30. gallopingcamel says:

    All this computer gibberish makes my head spin but I did pick up on a couple of points.

    The ModelE is based on a series of Hansen papers. Then there is the mention of needing 88 cores to run the code in a reasonable time. It all sounds really impressive until you realise that ModelE can’t do a decent backcast. If it can’t explain the past why waste a minute on this piece of garbage?

  31. E.M.Smith says:

    @G.C:

    Because it is the hammer with which we are beaten, regularly. So I’m setting out on what is likely a long journey to make my own battle hammer… based on a corrected one of theirs (so it can’t be totally tossed as amature garbage code… but the differences from theirs must be attacked, therefore addressed…)

    Worst case is, it showes how the results are largely assumption and parameter driven…

    @Pearce & Sandy:

    Both links are interesting. Both suffer from the “I have a hammer so everything is a nail” problem. They do a nice job of presenting alternative drivers, but leave out any numerical size measured… If you can’t show the size matches the history, it can mean everything or nothing…

    The Ocean MOC paper (2nd link) looks best to me, and does some sizing; but ignores what drives the MOC to change… so needs one more level of depth…

    The ANN posting suffers from being ANN based. Neural Nets have the problem that they are trained and learn, but you don’t know WHAT they learned. There’s the old story of the N.Net trained to spot Russian vs. American tanks in photos. Eventually was 100% accurate, even on partial tanks. So the researchers started cutiing down the photos. How little tank was enough? Well, it got 100% even with parts of the photo with NO tank in it. Just leaves or even sky…

    It had learned that the USA tanks were shot with 100 ASA while spys used 6400 to 3200 ASA film. It learned to measure the grain in the film used… so not useful as a battlefield tank spotter…

    So I’d need to see more before believing his ANN correctly ascribed causality…

    That both point out alternative mechanisms, presently being ignored,, says a lot.

  32. p.g.sharrow says:

    It is possible that elements in the logic of the code are correct but stitched together in a manner that results in the wanted answer rather then the correct one. Such as Mann inverting part of the tree records to yield his wanted temperature proxy.
    We may well have had well meaning contributors, poorly led coders being directed to present preconceived answers to justify enlarging grant funding as well as “Scientific Stature”.
    The question becomes, Do you throw out everything and start over or look for salvage?
    These guys spent hundreds of millions of dollars and years of effort to create this “Master Piece”. Can it be patched or modified without too massive an effort? There is now 25 years more data and we know that earlier records are being modified to make the model code yield the required answers…pg

  33. Another Ian says:

    E.M.

    If you’ve got what I suspect you’ve got see how they handle plant evapotranspiration.

    I was at a seminar at CSU in 1988 and the plant physiologist giving it had just seen the workings of the “latest and greatest”.

    And he was horrified. Plant ET was handled with a model of ONE plant stomate extrapolated to the world! Maybe just a bit of fudging room here?

    Early 2000’s I told that story in company of people here around the global gcm scene and said that I hoped better computers and more information had improved things. To be told that if anything they were worse.

    Colour me a rejecter until there is better bloody evidence of a link between CO2 and CAGW

  34. cdquarles says:

    I took a look at this (dang, has it really been that long?) in the ’07 to ’09 time frame. I am not sure that I still have an archive of EdGCM from back then. I may pick this computer game up again.

  35. EM – this dependence on the input data being within very tight bounds in order that the program doesn’t spiral out of control seems indicative of a lot of positive feedback inside the program itself. On the other hand, of course, we see that the real world must have negative feedback even though there are two stable temperatures available, with somewhat of a barrier between them, so that it will tend to stick in one range until it flips to the other.

    If the model itself was correct, then feeding it input data that is outside the bounds should iterate to conditions in one of the two stable temperature bands. If the information on the performance of the program with a “bad” dataset is correct, then the program instead has a single narrow band of relative stability and if for some reason it goes outside that then it won’t get back again. Such a program will predict disastrous consequences (either spiralling temperatures to a Venus-like set of conditions) or an ice-ball, once you step outside the current set of conditions.

    The dataset itself sounds to be huge and would itself take a lot of time to input. With only an 8° by 10° grid, though, that gives only around 810 cells for which the data needs to be put in. It also seems that the dataset from one cell to the next may not change a large amount, with a lot of copy/paste being possible in setting initial conditions. I haven’t seen a definition of the vertical structure of each cell, which would probably multiply that initial number of cells by some number, but the air-only cells would likely also have a lot of parameters the same to start with.

    At the moment, I’m seeing the insistence on the input data being within narrow bounds as being a tacit admission that the model is wrong. Though GIGO will obviously apply, if fed a dataset that is wrong it ought to iterate to one of the known stable temperatures. It’s going to take a lot of work to find out what assumptions are wrong, and maybe even to tease out the underlying assumptions and equations.

    Trouble is, that’s only one of the 14 or so models in use at the moment.

    The neural net and tanks story is informative. People are experimenting at the moment with computer-written code that evolves until it does the job required. Cheaper even than those H1B visa people, but also has the problem that you don’t know what it’s actually doing but only that it gives you the right answer as far as you’ve tested. Miss something out of the testing and some bad data going in could give surprising results. With pressure from the accountants to make the testing phase cheaper and quicker, it’s easy to predict some “interesting” results.

    I’ll look forward to seeing what results you get, but I think that you’ll probably end by proving that the code was ill-specified in the first place. There may however be a good basis for the structure in there – they can’t have got it totally wrong.

  36. pearce m. schaudies says:

    Hi Chief. With so many unanswered questions popping up on the EdGCM and the huge data set why not fall back to the GCM ii, the earlier version and maybe it’s more general and usable.

    I also saw some JavaScript models on internet. They may be too simple however.

    Regards, Pearce M. Schaudies.
    Minister of Future

  37. pearce m. schaudies says:

    Hi Chief. If you haven’t chekd the wiki, it tells more than you might need. Also, there may be a pony hiding in there, heh.

    https://en.m.wikipedia.org/wiki/General_circulation_model

  38. pearce m. schaudies says:

    Hi Chief. Here’s another link. Some models can download source an compile.

    https://www.gfdl.noaa.gov/model-development/

  39. E.M.Smith says:

    Pearce,

    I am just using the GCM Model II. But the only way to get the sources is to extract them from eduGCM as NASA has removed them from public access. Essentially it looks like they cut a deal to let edGCM make money off it and publish it wrapped in a nice GUI to isolate you from the FORTRAN.

    As it is older, smaller, and simpler, I’m starting with the Model II code as a stepping stone to Model E, that I’ll be looking at next. I suspect it is an incremental advance and much of the core will be based on Model II. If need be, I can likely make a lighter and faster MedelE based system by cutting it back to the precision of Model II… I found a reference stating the computes go up as the 4th power of resolution… (3 physical dimensions plus time step?) So likely a small reduction in granularity could make a big reduction in hardware needed… in which case, the Model II choices for tuning would be good to know. So cut resolution in half, your 88 cores would become 2x2x2x2= 16 88/16= 5.5 or 6 cores. That is high end desktop scale today.. The Model II docs say low res works well enough… so…

  40. E.M.Smith says:

    Oh, and I probably ought to note that for anyone just wanting to download and run the edGCM version, the link is here: http://edgcm.columbia.edu/download-edgcm/

    It demands an email address (then sends a link to the actual download) and then also starts your “30 day free trial”… and with some (to me at least so far) unknown cost to keep using it.

    Nice that they are making money off of the NASA public domain software (and their added private GUI wrapper…) I guess… but having the config files available for download along with the GCM itself would be a “good thing” for those of us playing in Unix / Linux land… Oh Well…

    (A case can be made that programming consists of data structures and algorithms. Having only the algorithms available via the software and demanding money to get to the data structures that make it run is at best a violation of the ethics of making the public portion of GCM Model II available… Their GUI wrapper and process is theirs, as is their database design, and charging for that is their privilege).

  41. Pingback: Inside GCM Model II | Musings from the Chiefio

  42. Larry Ledwick says:

    I wonder if a FOI request from Heritage Foundation or some similar group could shake loose those data structures for public access?

    If you have a two part process and only one of them is openly available you have not made the process a “public record” even though it was developed with public funds at tax payers expense.

  43. E.M.Smith says:

    Larry:

    One could always take the 30 day ‘trial’ and extract the data structures from their database, then make the case they are public data portions. I’m not seeing the need, though.

    Today I did a quick look at ModelE. It is available with all the “rundecks” and input files and several of them are the same basic data (just more resolution in the data files). So worst case I just ‘derez’ some of them (i.e. average / interpolate the larger grid cell data of Model II)

    But even beyond that: Looking at the computes needed, and their idea of a ‘reasonable run time’ and then mixing with that 1/2 the resolution gives 1/16 the CPU demand, I’m thinking that a ModelE port might be ‘reasonable’. (It already is touted as running on most any Linux / Unix…)

    Then season with the point that only the full ocean dynamics with atmospheric chemistry needs all 88 cores, and Model II doesn’t do them anyway… so a “Model II like run with Model E” is likely in the ‘doable’ range.

    So after a look at the Model II code to familiarize with it, I’m going to do a cursory scan of the Model E code just to see if it is at all similar (I expect the core is remarkably the same, given the general GISS approach of reused bits and an archeological dig aspect in the comments… IBM 360? RS6000?… )

    IFF all that ‘checks out’, I’m going to try a run of the reduced features Model E just to size things, then cut it back as needed. (Simply reducing grid scaling ought to be pretty easy… add data points together by 2s for the input files, and cut array bounds in half, ought to cover a lot of it.) Heck, I might not even need to do that. It supports distributed (MPI) processing, and with the Model II speeds saying it does days worth of runs in minutes to hours, using 12 cores of Pi on a reduced features Model E might just give a usable model run in a day or three; and that’s FINE with me.

    In all cases, it’s a while more whacking on code before “design decisions” ought to be made. I’m also comfortable that ‘enough’ of the input parameter file data is readily available (even if the form is a bit off) that I can make even Model II “go” … though at the expense of a week or two of data herding. I’ve done worse…

    In the end, it reduces to:

    Collect and format a load of input data files from reasonably available sources (even if it takes sucking it out of images on a Hansen paper…)

    v.s.

    Trim back the ambitions of Model E and maybe do a systematic data array compression.

    Neither one looks particularly hard (though booth look a bit the bother…)

    If, in the end, I get a Public Domain Free Licensed Climate Model with some of the silly squashed out of it, well, that’s a pretty big feature…

    Of all the “issues”, the one that bothers me the most is just that my tests of Parallel FORTRAN on the Pi have had it run SLOWER than as straight code. One hopes the MPI method is not so afflicted. (I need to create and run some kind of benchmark on that…)

    I’ve been running with OpenMP, not MPI, so “your milage may vary”… OpenMP looks like:

            !$OMP PARALLEL DO
            do j = 1 , nmc
               print *, 'Experiment', j
               mu(j) = monte_carlo(n)
            end do
            !$OMP END PARALLEL DO
    

    which gives a compiler directive to unroll the “do loop”. MPI spins out larger chunks of programs for remote running on other CPUs / computers, not just multiple threads in a multicore chip. So I have some hope MPI will work better on the Pi.

    But that’s way down the road and deep in the weeds. For right now, I’ve got some 1988 vintage FORTRAN to wade through…. (Anyone got some hotsauce? This code is mighty chewy and flavorless and could use help in the swallowing ;-)

  44. Larry Ledwick says:

    It would be nice if you can find a way to go through the back door to get open source data files to make the model work and side step their data down load profit center.

    Given all the digging that took place during email-gate, someone might have harvested those files somewhere from an open FTP server that they did not close down. As I recall they “leaked” a bunch of information around that time by sloppy management of their files, and people found open access files that were available for the free download at the time.

    Maybe some of the data packrats over at WUWT have archived what you need. If so it might also be better quality being compiled before all the recent adjustments.

  45. E.M.Smith says:

    @Larry:

    Don’t stress over it. The Hanson 87? paper has some of it included, and at the grid scale used the resolution is crap anyway, so easily made from the available data. More importantly, I’ve started looking at ModelE and like the way it uses MPI. It ought to parallelize much better and easier than Model II AND is designed to run on a cluster of different architecture machines. This means, for example, that mixed Pi and Intel boxes ought to work fine. That’s a BIG deal…

    Though, per ModelE, it’s a bit bigger with a LOT more moving parts (even if many are small)… A brief “look ahead”:

    sh-4.3$ wc -l *.f
         565 ADVSIcs.f
          67 AFLUXES.f
         876 ALBEDO.f
          82 ALLOC_DRV.f
        3581 ATMDYN.f
        2148 ATMDYN2.f
         188 ATMDYN_COM.f
         976 ATMDYN_SCM.f
         188 ATMDYN_SCM_COM.f
          62 ATMDYN_SCM_EXT.f
        1001 ATM_DUM.f
         848 ATM_UTILS.f
        1378 ATURB.f
        1240 ATURB_E1.f
         214 BIOGENIC_EMISSIONS.f
        6492 BLK_DRV.f
         365 CLD_AEROSOLS_Menon.f
         469 CLD_AEROSOLS_Menon_BLK_MAT.f
         561 CLD_AEROSOLS_Menon_IPCC.f
         507 CLD_AEROSOLS_Menon_MBLK_MAT.f
         507 CLD_AEROSOLS_Menon_MBLK_MAT_E29q.f
        7179 CLOUDS2.f
        3272 CLOUDS2_DRV.f
        5446 CLOUDS2_E1.f
         384 CLOUDS_COM.f
           6 CONST.f
         539 COSMO_SOURCES.f
         251 COSZ_2D.f
        7501 DEFACC.f
        5703 DIAG.f
        2533 DIAG_COM.f
        4877 DIAG_PRT.f
          10 DIAG_RES_C.f
          10 DIAG_RES_F.f
          11 DIAG_RES_M.f
          56 DIAG_ZONAL.f
         126 DIAG_ZONALcs.f
         193 DOMAIN_DECOMPcs.f
         559 DRYCNV.f
         475 ENT_COM.f
         404 ENT_DRV.f
         400 ENT_DRV_devel.f
         505 FFT144.f
         488 FFT288.f
         495 FFT36.f
         456 FFT72.f
         143 FFTW_COM.f
         427 FLUXES.f
        3127 GCDIAGb.f
        1559 GCDIAGcs.f
         849 GEOM_B.f
         310 GEOM_CS.f
           6 GHY.f
        1000 GHY_COM.f
        5376 GHY_DRV.f
           6 GHY_H.f
          63 GLMELTt2b.f
         661 GNOM_CS.f
        1388 ICEDYN.f
        2339 ICEDYN_DRV.f
          98 ICEDYN_DUM.f
         141 ICEDYNo_DUM.f
         168 IORSF.f
         566 IO_DRV.f
        2652 LAKES.f
         272 LAKES_COM.f
         582 LANDICE.f
        1058 LANDICE_DRV.f
        2628 MODELE.f
         824 MODEL_COM.f
         572 MOMEN2ND.f
         634 MOMEN4TH.f
         353 NUDGE.f
          42 OAtoAA_CS.f
        1426 OCEAN.f
          47 OCEANR_DIM.f
         575 OCEAN_COM.f
        1452 OCEAN_hycom.f
        5641 OCNDYN.f
        1998 OCNDYN2.f
         405 OCNFUNTAB.f
        1478 OCNGM.f
        2388 OCNKPP.f
         229 OCNML.f
         897 OCN_Int_CS.f
        1951 OCN_Int_LATLON.f
        2568 OCN_Interp.f
         645 OCN_TRACER.f
         107 OCN_TRACER_COM.f
         763 OCN_mesosc.f
         573 ODEEP.f
        2089 ODIAG_COM.f
        2407 ODIAG_PRT.f
         444 OFFT144E.f
         488 OFFT288E.f
         356 OFFT72E.f
         641 OFLUXES.f
         171 OGEOM.f
          63 ORES_1Qx1_L32.f
        1097 OSTRAITS.f
         132 OSTRAITS_1QX1_COM.f
         124 OSTRAITS_1QX1_COM_21K.f
         113 OSTRAITS_21k_COM.f
         121 OSTRAITS_9ky_COM.f
         120 OSTRAITS_COM.f
         120 OSTRAITS_F_COM.f
         118 OtoA.f
           6 PARAM.f
           6 PARSER.f
        3744 PBL.f
         549 PBL_COM.f
         889 PBL_DRV.f
           2 PBL_E1.f
          70 PBL_SIMPLE.f
         318 PBL_SIMPLE_DRV.f
         828 POUT.f
        1698 POUT_netcdf.f
           8 QUICKPRT.f
        2360 QUS3D.f
         801 QUSDEF.f
         194 QUS_COM.f
         611 QUS_DRV.f
        1856 QUScubed.f
       10728 RADIATION.f
           2 RADIATION_E1.f
         888 RAD_COM.f
        4074 RAD_DRV.f
           2 RAD_DRV_E1.f
        3419 RAD_UTILS.f
         324 RAD_native_O3.f
          54 RES_2Hx2_L13.f
          63 RES_2Hx2_L32.f
          54 RES_5x4_L13.f
          63 RES_5x4_L32.f
          62 RES_C12.f
          64 RES_C20.f
          49 RES_C23.f
          42 RES_C32M20AT.f
          65 RES_CS48L20.f
          42 RES_CS90L40.f
          62 RES_F12.f
          65 RES_F20.f
          48 RES_F23.f
          68 RES_F40.f
          53 RES_F53.f
          79 RES_F79.f
          62 RES_M12.f
          64 RES_M20AT.f
          47 RES_M20S.f
          48 RES_M23.f
          48 RES_M24S.f
          65 RES_M24T.f
          53 RES_M53.f
          44 RES_OV13.f
          51 RES_OV32.f
          68 RES_X40.f
          45 RES_stratF40.f
          50 RES_stratX40.f
          52 RES_stratX53.f
        1790 SCMDATA_SGP.f
        1479 SCMDATA_SGPCONT.f
        1692 SCMDATA_TWPCRM.f
        1466 SCMDATA_TWPICE.f
         257 SCM_COM.f
        1029 SCM_DIAG.f
          80 SCM_DIAG_COM.f
        2657 SEAICE.f
        1424 SEAICE_DRV.f
           6 SNOW.f
           6 SNOW_DRV.f
        1539 STRATDYN.f
         935 STRAT_DIAG.f
        2941 SUBDD.f
        1809 SURFACE.f
           6 SYSTEM.f
        2264 TES_SIMULATOR.f
        1108 TQUS_DRV.f
        2903 TRACERS.f
        2563 TRACERS_AEROSOLS_Koch_e4.f
       12640 TRACERS_DRV.f
         304 TRACERS_O18.f
        1561 TRACERS_SPECIAL_Shindell.f
        1195 TRACER_COM.f
         239 TRACER_GASEXCH_CFC.f
         241 TRACER_GASEXCH_CO2.f
         509 TRACER_HETCHEM.f
         157 TRACER_NITRATE.f
         434 TRACER_NITRATE_DRV.f
        1943 TRACER_PRT.f
        1722 TRACER_SPECIAL_Lerner.f
         478 TRAMP_actv.f
        1204 TRAMP_coag.f
         180 TRAMP_depv.f
         129 TRAMP_diam.f
         635 TRAMP_dicrete.f
         583 TRAMP_drv.f
         562 TRAMP_init.f
       18249 TRAMP_isocom.f
        6421 TRAMP_isofwd.f
        3506 TRAMP_isorev.f
        1327 TRAMP_matrix.f
         193 TRAMP_nomicrophysics.f
        1479 TRAMP_npf.f
         403 TRAMP_param_GISS.f
         283 TRAMP_quad.f
         660 TRAMP_rad.f
        1613 TRAMP_setup.f
         247 TRAMP_subs.f
         179 TRAMP_thermo_eqsam.f
         164 TRAMP_thermo_isorr.f
         826 TRCHEM_Shindell_COM.f
        1863 TRCHEM_calc.f
         643 TRCHEM_family.f
        1390 TRCHEM_fastj.f
        1557 TRCHEM_fastj2.f
        1017 TRCHEM_init.f
        2795 TRCHEM_master.f
        1363 TRDIAG.f
        1483 TRDIAG_COM.f
        1105 TRDRYDEP.f
         744 TRDUST.f
         337 TRDUST_COM.f
        1265 TRDUST_DRV.f
           6 TRIDIAG.f
           6 UTILDBL.f
           6 VEGETATION.f
         283 VEGTYPEt2b.f
         172 VEG_COM.f
         786 VEG_DRV.f
         237 advc1d.f
         277 advem.f
         263 advfct.f
         503 archyb.f
         296 barotp.f
         259 bigrid.f
          35 blkprf.f
           1 checkpoint_demo.f
         855 cnuity.f
         231 convec.f
         745 cpler.f
         245 cplercs.f
        3203 cs2ll_utils.f
         374 diapfx.f
          63 dpthuv.f
         105 dpudpv.f
         155 eice.f
         756 exact-regrid.f
          45 faa_com.f
         204 flammability.f
         374 flammability_drv.f
         640 geopar.f
        1186 hybgn1.f
        2035 hycom.f
         431 hycom_arrays.f
        1046 hycom_arrays_glob.f
         258 hycom_arrays_glob_renamer.f
         243 hycom_atm.f
         161 hycom_dim.f
         232 hycom_dim_glob.f
         270 hycom_scalars.f
         296 inicon.f
        1413 inigis.f
         140 inikpp.f
         426 irrigation.f
         372 kprf_arrays.f
         105 kprf_arrays_loc_renamer.f
         125 krturn.f
         291 lightning.f
         159 matinv.f
        1003 momtum.f
        3632 mxkprf.f
         572 mxlayr.f
         199 obio_alkalinity.f
         244 obio_archyb.f
        1359 obio_bioinit.f
         957 obio_bioinit_g.f
         966 obio_carbon.f
         317 obio_com.f
         170 obio_daysetbio.f
          51 obio_daysetrad.f
         210 obio_diffmod.f
          82 obio_dim.f
         362 obio_edeu.f
         129 obio_forc.f
         174 obio_incom.f
         865 obio_init.f
          75 obio_limits.f
        1170 obio_model.f
          49 obio_oasimhr.f
         201 obio_ocalbedo.f
         790 obio_ptend.f
         550 obio_reflectance.f
          56 obio_sfcirr.f
         256 obio_sinksettl.f
         389 obio_trint.f
          55 obio_update.f
         683 pario_fbsa.f
        1021 prtetc.f
        1100 rcpTRCHEM_init.f
         148 read_faa.f
         258 reflux.f
        1780 regrid.f
         206 regrid_com.f
        2650 regridinput.f
         592 relaxGOCC.f
        1068 sigetc.f
         592 test_regrid.f
         197 thermf.f
         831 trcadv.f
         342 tsadvc.f
      309239 total
    

    OMG, 309 K lines of FORTRAN code?… well at least most of them can just be accepted as is and the input files molested instead ;-)

    After all, it is only 310 different FORTRAN programs ;-)

    I think I can make something functional that’s at the 1/2 way point between Model II and ModelE…

  46. cdquarles says:

    Heh, I found my archive. I created it in 2008. It has 2007 dated files in it.

  47. Pingback: Carping Comments – Idiots and “poseur” | Musings from the Chiefio

  48. Pingback: Carping Comments – Idiots and “poseur” | Musings from the Chiefio

  49. E.M.Smith says:

    @P.G.:

    I’ve saved the GHCN V1 and V2 data… One of my “someday” projects is a MySQL database loaded with all the versions I have so I can compare and contrast the “raw data” from different versions.

    Oh, and I’m going to check my email, honest! Just some 10 year old Speyburn hauled me aside and beat me senseless ;-) It’s not my fault, though, he called my Pi Model 3 “A Garbage Scow!”… I mean, I can take a few insults, that that was too much! ;-)

    Per the model:

    Near as I can tell, where they have physics, they correctly code it. Where it is not possible at that scale, they apply a ‘good approximation’ (so for example, sub-grid scale clouds get a ‘plug number’ based on what they measure happened in {some grid} in {some place} at {some time} and extrapolated instead of modeled.

    Where they don’t know, they “make a good guess”.

    Near as I can tell from the first cursory review (and subject to massive change once I get deeper in it) they are, in fact, making a good faith effort to get the physics right. BUT, some of the factors are “fudge” as they don’t know or can’t model at that scale. Then they make the fatal mistake of believing they got it right…

    IMHO: “Models are best used to ‘inform our ignorance'” -E.M.Smith

    So, for example, some kind of general vegetation plug values are used (there’s an input file with the type of vegetation in each grid cell as gross values) and they assume that they have the physics of evapotranspiration right for all mixes at all times of day in all climates. Yet we know cactus has a very different behavior from Oaks and Pines, and that since the model was built we’ve learned many kinds of trees control EvTr to try to maintain an 86 F canopy temp. NOT in the model…

    As another example, they set a TSI value (and even vary it with orbital mechanics), yet completely MISSED that UV can vary by 10% (and IR) during long term solar cycles and that changes where the energy goes, making all those atmosphere energy layer calculations a bit daft… as they don’t include that.

    It is that kind of stuff where I need to dig in and find the “ignorance” that needs informing.

    Now, what they did do (per the readings not in this article) is find the model unstable and not conformant to reality is many cases. So they tuned the input (those missing input files for things like land cover type and all) until it reasonably well modeled reality in the past. The assumption being that this made the model right when it just makes the model consistent with history given the wrong formulas. That is where they went fully off the rails, IMHO. That, too, is likely where they got too much moisture in the upper atmosphere.

    Now my approach is different. I’m going to get it going, then set it so it gets the atmospheric moisture right. THEN look at the output and how it differs from reality to “inform my ignorance” about what is likely missing that would change that.

    Similarly, add in a UV / IR layer distribution and separate handling of UV, Visible, IR energy distribution on insolation. Then run with a “solar cycle” driver file with the solar state history. At that point, we ought to see the Great Pacific Shift of the middle 70s as it got warm in a step change AND the present step change to cooler (though perhaps with lags…). IF not, I won’t throw out that code, I’ll use it to “inform my ignorance” about what else might be needed.

    That’s the fundamental difference of approach. They TRUST the model to be right. I EXPECT the model to be wrong and tell me where to look next. (Until such time as it IS right and matches reality AND predicts the future accurately…)

    @CDQuarles:

    IF you happen to have any of the input files, I’d be very interested in getting a copy…

    @Simon:

    Yeah, that instability issue speaks to me too. Clearly we have two stable ends with hysteresis between them. Ice Age Glacial and Interglacial. This seems driven by the tilt of the earth (TSI above 60 N) and land mass distribution on geologic time scales. Shorter term, ocean current cycles drive much of it.

    On a “someday” basis, having a better ocean model would be needed. For now, it’s likely good enough given stationary land masses, not significant ocean depth change, and modest changes to ocean heating. Unfortunately, adding UV to deep ocean vs not is likely going to be a ‘bit wrong’ if it isn’t allowed to shift ocean circulation…

    But if you don’t have 2 stable states (iced and not-iced) you are wrong. Likely limited by ice formation physics at the cold end and water vapor heat transport to the tropopause at the warm end, and with the warm end good…

  50. cdquarles says:

    I’ll check it but I don’t think there are any input files. How should I get it to you?

Comments are closed.