Add inp save function

[bemcdonnell]

No description provided.

[kakila]

I propose that the first task is to port the code in Uexport.pas in the GUI source folder (GUI5_1_012) to C/C++ or directly to python (this would be even easier). What do you think?

[goanpeca]

Yes Python easier, but not the definitive solution. It should be C or C++ for it to be useful

[kakila]

Then lets make it C++ (you mean useful for the future multilanguage API based on SWIG?)

As I am just getting tinto the community. Is there a coding style guideline?

[goanpeca]

Useful for anyone wanting to use whatever other language they see fit, be it python or ruby or whatever. And yes useful also for using SWIG.

[michaeltryby]

@kakila Uexport.pas is one example and EPANET inputfile.c is another.

[kakila]

@michaeltryby thanks, I am not familiar with inputs to EPANET. Is there any major differences between inp for EPANEt and inp for SWMM? If there isn't then the work is reduced to refactoring inputfile.c

[goanpeca]

inputfile.c and uexport.pass could become either

• single io.c, or
• import.c and export.c or
• input.c or output.c

I mean just to be consistent with the naming (actions that are reflective)

[kakila]

@goanpeca is there a coding style guideline? where would you place this file? what is the naming convention?

[goanpeca]

@goanpeca is there a coding style guideline? where would you place this file? what is the naming convention?

I have no idea :-p, @michaeltryby is our man here

[bemcdonnell]

Lew's style. :-)

[goanpeca]

Right now all files are just dumped together, maybe we could add some structure to the source files?

src/engine/ -> *.c files referring to the engine
src/io/ -> *.c files referring to the input output of the model
src/tools/ -> *.c files referring to common use tools of use in any other part of the code?
src/headers/ -> *.h files for everything?

[michaeltryby]

@kakila EPANET and SWMM input files are organized the same way using tagged file sections. It might be useful to study up on the input file format in preparation for your project.

[bemcdonnell]

@goanpeca,

before we do:

src/engine/ -> *.c files referring to the engine
src/io/ -> *.c files referring to the input output of the model
src/tools/ -> *.c files referring to common use tools of use in any other part of the code?
src/headers/ -> *.h files for everything?

let me do some re-orging. I've got a couple of pull requests hang around and I want to bring them in first.

[michaeltryby]

Lew's style uses functional abstraction as the primary organizing principal, clearly named functions and variables, copying his coding idioms and idiosyncrasies, a comment header for every function, peppering the source code with helpful comments.

We need to establish and enforce a coding standard.

[kakila]

In Octave we use http://wiki.octave.org/C%2B%2B_style_guide after 10+ years of using it I must admit it is very readable and it does provide a speed up when browsing code. For python many of the styles not need apply, e.g. function calls and array accessing is already differentiated.

[goanpeca]

For reference I opened #48

[kakila]

Is there an editable wiki in this project or should I just add information about the EPANET and SWMM input files here?

[goanpeca]

Yep the wiki is editable by people with write access.. :-p

[kakila]

@goanpeca I meant that "I can edit". I guess I will have to use these comments.

[kakila]

.inp file sections

Section	EPANET [*]	SWMM[**]	Same?
ADJUSTMENTS		x
AQUIFERS		x
BACKDROP		x
BUILDUP		x
CONDUITS		x
CONTROLS	x	x
COORDINATES	x	x
COVERAGES		x
CURVES	x	x
DEMANDS	x
DIVIDERS		x
DWF		x
EMITTERS	x
ENERGY	x
EVAPORATION		x
EVENTS		x
FILES		x
GROUNDWATER		x
GWF		x
HYDROGRAPHS		x
INFILTRATION		x
INFLOWS		x
JUNCTIONS	x	x
LANDUSES		x
LOADINGS		x
LOSSES		x
MAP		x
MIXING	x
OPTIONS	x	x
ORIFICES		x
OUTFALLS		x
OUTLETS		x
PATTERNS	x	x
PIPES	x
POLLUTANTS		x
Polygons		x
PROFILES		x
PUMPS	x	x
QUALITY	x
RAINGAGES		x
RDII		x
REACTIONS	x
REPORT	x	x
RESERVOIRS	x
SNOWPACKS		x
SOURCES	x
STATUS	x
STORAGE		x
SUBAREAS		x
SUBCATCHMENTS		x
TAGS		x
TANKS	x
TEMPERATURE		x
TIMES	x
TIMESERIES		x
TITLE	x	x
TRANSECTS		x
TREATMENT		x
VALVES	x
VERTICES		x
WASHOFF		x
WEIRS		x
XSECTIONS		x

In seems the files are not subsets of each other. I will focus on SWMM (more sections) hoping that the sections with the same are are the same (same parametrization and meaning).

[*] as given in inpfile.c
[**] as given in Uexport.pas

[DJHostetler]

I am able to pitch in and help with this effort.

[bemcdonnell]

@DJHostetler, awesome! Well this contribution can start from our develop branch.

[dickinsonre]

The SWMM list is missing the LID sections and Events, and there are a few characters missing from some of the SWMM section names
SectionWords : array[0..54] of PChar = //(5.1.011)
('[TITLE', //0
'[OPTION', //1
'[RAINGAGE', //2
'[HYDROGRAPH', //3
'[EVAPORATION', //4
'[SUBCATCHMENT', //5
'[SUBAREA', //6
'[INFILTRATION', //7
'[AQUIFER', //8
'[GROUNDWATER', //9
'[JUNCTION', //10
'[OUTFALL', //11
'[STORAGE', //12
'[DIVIDER', //13
'[CONDUIT', //14
'[PUMP', //15
'[ORIFICE', //16
'[WEIR', //17
'[OUTLET', //18
'[XSECTION', //19
'[TRANSECT', //20
'[LOSS', //21
'[CONTROL', //22
'[POLLUTANT', //23
'[LANDUSE', //24
'[BUILDUP', //25
'[WASHOFF', //26
'[COVERAGE', //27
'[INFLOW', //28
'[DWF', //29
'[PATTERN', //30
'[RDII', //31
'[LOAD', //32
'[CURVE', //33
'[TIMESERIES', //34
'[REPORT', //35
'[FILE', //36
'[MAP', //37
'[COORDINATES', //38
'[VERTICES', //39
'[POLYGONS', //40
'[SYMBOLS', //41
'[LABELS', //42
'[BACKDROP', //43
'[PROFILE', //44
'[TABLE', //45
'[TEMPERATURE', //46
'[SNOWPACK', //47
'[TREATMENT', //48
'[TAG', //49
'[LID_CONTROL', //50
'[LID_USAGE', //51
'[GWF', //52 //(5.1.007)
'[ADJUSTMENTS', //53 //(5.1.007)
'[EVENT'); //54 //(5.1.011)

[michaeltryby]

@DJHostetler Great to have you aboard!