elminateFortran.md

Improve development workflows by transition all E+ utilities to C++/Python

Despite the core of E+ being fully transitioned to C++, there are a number of legacy stand-alone projects in E+ that still require developers work in FORTRAN or other languages. The following is a list of all current FORTRAN projects remaining in the E+ project.

• Basement
• CalcSoilSurfTemp
• ConvertESOMTR
• ExpandObjects
• HVAC-Diagram
• ParametricPreprocessor
• ReadVars
• Slab
• Transition

Basement and Slab programs can be eliminated, at some point, and transitioned to the new basement and slab objects incorporated into E+.

CalcSoilSurfTemp can be incorporated into E+. New ground temperature models are already reading the weather file, so adding this code to E+ would be relatively simple. It would also allow an "Autocalculate" option for the KA ground temp model.

ReadVars, HVAC-Diagram, Transition, and possibly others could be converted to a Python based program or eliminated as deemed appropriate.

There are also other VB6 programs included in the E+ project. The following is a list of all VB projects included in E+:

• EP-Launch
• IDFEditor
• IDFVersionUpdater
• WeatherConverter

Some benefits to pushing everything to C++/Python:

• Python can be packaged as an exe using py2exe or some something similar. This exe would give the same functionality to users as the current system and not require a Python installation.
• Eliminate need to package/ship basic runtime libraries (support for VB6 ended in 2008). There is at least one open issue related to this: NREL/EnergyPlus#5105
• Eliminate the need for FORTRAN compiler and FORTRAN specific build/testing support
• Makes the project more accessible to outside developers who are likely to be more familiar with OO design, Python, and C++ over FORTRAN and VB.
• Make utilities cross-platform compatible.
• Simplifies project setup and testing by simplifying CI machines configuration.
• Some of these utilities will require an input processor. This could be a shared routine if converted to Python, or if/when E+ goes to JSON input, native Python JSON libraries could be utilized, which eliminates the need to maintain an input processor in Fortran or VB.

Ultimately, IMO, this would help push the E+ project to a standard format of C++ code for performance/heavy number crunching-type work, and Python for scripting, utilities, and all other non-core E+ project related work.

These could possibly incorporated into E+

There are reasons not to do that, so I'd leave that out. Maybe itemize the pros (cons?) in a bulleted list instead of just in the next-to-last sentence. Otherwise that seems quite reasonable.

This would look the same to the users

Make sure this is clear. I know you know it doesn't mean the graphics look the same, but well, some people. In addition, the users don't see an exe anyway, most likely, they just launch it from the command line, so don't sweat that it is Python instead of a binary blob. My point was that they won't have to install a separate program (Python) in order to get this to work on their machine.

Then I would consider describing the actual work process. Some of these programs will have to have an input processor (IDF Editor, Parametric Preprocessor, Transition). Will that be a Python script? Or more likely, you would note how we will be in JSON land soon-ish, and you'll just use native Python JSON libraries 👍 👍 👍 👍 . Think of other gotcha's in actually doing the process in order to anticipate the other's questions.

@Myoldmopar Updated. Let me know if this looks better or there are other things I need to look into.