Does your model support root nodule nitrogen fixation? I've been looking for simulation software to estimate optimal levels of nitrogen fixers, but I didn't find any comprehensive models that included this. I didn't look at your model for it though; although I did come across it several years earlier when I was looking for plant growth simulations for another reason. In what way(s) does it diverge from EPIC? EPIC & APEX are (widely) applied for policy evaluation purposes (how much sense that makes is another matter, but let's just accept reality for now); is your model robust enough for such things, I mean comparable to EPIC? And does it still run on Windows 10? I tried to install it but got some error that it failed writing to a registry key, and then I didn't look any further.
Most of the model source code is derived from EPIC (and a bit from SPUR which was about rangelands, weather, and plant competition). The EPIC conversion involved a person-year of painstaking work going through EPIC and creating sensible names for the cryptic FORTRAN variables (which were also sometimes reused multiple times with different meanings) and short function names as the code was rewritten into C++ and then later Delphi. My wife -- who I met via the PhD program in Ecology and Evolution I went to to try to learn enough to write the simulator -- did most of that translation.
It's been twenty years, so I could not answer detailed questions about it of the top of my head without digging into the code (and maybe not even then). But the core parts of the soil percolation model should be very close to EPIC's code and data. The source code for the soil models references the EPIC equations and the related scientific literature.
The simulator was written under earlier versions of windows (Win 3.1 and 95), and from around WinXP and later it seems the code that updates the registry causes an error. Not sure how to easily work around that.
Here is the file you would want to focus on first, and it does mention nitrogen fixation and nodules, but you'd have to make your own decision about how useful that was to you as a reference:
https://github.com/pdfernhout/GardenSimulatorSourceCirca1997...
Remember that a lot of EPIC is empirically derived functions and values from US soils in certain climates -- so it may not be totally applicable elsewhere, even if it is a place to start.
I put our PlantStudio and StoryHarp code up on GitHub (which share some common code with the garden simulator) and have been meaning to someday put the garden simulator code there.
I spent a couple of months about a decade ago porting part of the code base to Java and also Python which involved writing a Delphi parser and translation tool, but the result is not a finished work. But the converted code for the garden simulator is not on GitHub (yet). You can see some of the converted plant drawing code here though: https://github.com/pdfernhout/PlantStudio
I had wanted to help develop self-replicating space habitats and helping people grow their own food better seemed like a good first step towards that which both had short-term on-Earth benefits plus long-term benefits for space settlement. We did this all on our own money from consulting and also credit cards. When they were maxed out (~US$100K) we took unrelated programming jobs at IBM Research and elsewhere to pay it all back on-time with interest -- it took many years to get back to zero -- and we never got a chance to do that much more with the simulator...
Our (at first shareware) PlantStudio software was a spinoff for breeding virtual plants which got substantial interest from 3D modellers -- but even there, we did not have time to keep improving it since we were both working full-time the at IBM. PlantStudio was mainly my wife's project in response to user feedback from the Garden Simulator that people liked playing with the plant design part of it. We eventually made that free and then open source.
http://www.kurtz-fernhout.com/PlantStudio/userssay.htm
After that effort on our own, I'd get a bit annoyed I got when I'd watch NASA and other places give big grants to people who then made proprietary software with it. That motivated me to write essays like this back around 2001: http://pdfernhout.net/on-funding-digital-public-works.html "As a software developer and content creator, I find it continually frustrating to visit web sites of projects funded directly or indirectly by government agencies or foundations, only to discover I can't easily improve on those projects because of licensing restrictions both on redistribution and on making derived works of their content and software. ..."
But I can give kudos at the USDA ARS BRC and the EPIC team for developing their code in-house and putting it in the public domain. The EPIC developers (but not administrators) were annoyed a bit themselves at our own plan originally to make proprietary software from their models, which was another factor in our making that garden simulator effort FOSS.
Our hope had been to keep improving those models and getting more people involved in that process online with a 2.0 version of the software as a shared modelling environment. But our few small efforts to find funding to continue in that direction were not productive. I guess we were just better software developers than sales people. :-) Plus we have learned a lot since then about a more incremental development style.
http://gardenwithinsight.com/nsfprop.htm
Anyway, I can hope that using that Garden Simulator software as an initial reference point can help a next generation of soil scientists and free software developers create even better software for research, education, and applications from bringing soil anywhere back to life. :-)
Thank you, very interesting. I feel your pain wrt converting Fortran models; I've spend quite some time doing it for models similar to EPIC. In fact, about 7-8 years ago in a fit of hubris, we submitted a proposal as part of which I would integrate EPIC into some other models, as a part of which I would have to convert it to C++; IIRC I estimated about 6 months for it. TBH I do have large libraries of simulation framework, so it would mostly be understanding equations and converting them. Still, I'm happy we didn't win that proposal :)
The help section is impressive as well. It's clear that you each put a lot of work into this.
Thanks for sharing the code. I think this was my first time reading Delphi!
Porting it to JavaScript sounds like a significant endeavour. But also potentially worthwhile. The web could be a great way to share this.
