Wednesday, January 6, 2010
Developers Wanted / Specific Programming Needs
I would like to start a developers group for this program. If you have ideas and/or can make programming contributions, please join the project over at SourceForge. Click on the "comments" below this post to see a write-up of specific programming needs.
Subscribe to:
Post Comments (Atom)
This comment has been removed by the author.
ReplyDeleteIf you have ideas and/or can make programming contributions, please join the project over at SourceForge. I would like to start a developers group for this program. The SourceForge site documentation and support is not copious, so I’m a little unclear how to enlist programmers, make announcements, and use the version tracking software. Feel free to offer enlightenments there.
ReplyDeleteThe most critical development need at this point is with interprocess communication (IPC).
http://en.wikipedia.org/wiki/Inter-process_communication
and I currently have a SourceForge programmer helping me with it! He recommended using either Berkeley Sockets or shared-DLL files, although DLL's are Windows specific.
All the source codes and manual can be downloaded at the site following the link at the top of the blog. Currently the Graphical User Interface (GUI) is written in Visual Basic (VB) 5.0, while all of the grid reading / writing / creating and Modflow input file creation are done in Fortran. Each is compiled into executable files (separately running programs) that communicate and share data using text files. Thus the standard text files can be written within any given operating system. The GUI is only used for sending program commands (i.e. program option flags, I/O filenames, and simple integer or real constants) as text strings in files called "command#.txt" files. The command#.txt files are consecutively numbered (with #) throughout program execution. They are stored on disk and can thus be used to script the Fortran, running it without the GUI.
I avoided passing data to / from the GUI with pipes or through memory, in order to avoid committing the program to a specific GUI / operating system combination. I would like to keep it that way. This will allow the GUI to be changed-out to anything that can supply the command files, including a web browser or a human being. Thus all you need to do to “cross platform” the code is recompile the Fortran in the new operating system and use whatever GUI on that platform you want, ideally even a web-browser. The IPC is done by looping the Fortran while waiting for a file from the GUI, and using the operating system to signal when the file exists. The problem is that this sets up races between the operating system and the program, and if the operating system loses (e.g. the file exists in the registry but isn’t completed on disk), the program crashes.
I've got someone working on the IPC issue, so communicate with us before "re-inventing the wheel." I'm still open to recommendations here. Also, I know there are ways to dedicate files on the system to specific “instances” of the program so that multiple “instances” can be running without using another “instance’s” command file, but I do not know how to implement that. Any suggestions here would be welcomed also.
Roberto Maugeri pointed out that the visual basic project file, diasxnio1.4.vbp, was missing from the GeoSolid3D.zip download. I have now added it to the SourceForge site. The VB project makes diosxn1.4.exe which runs the other two exe's, diasxnio.exe and geosxn.exe, compiled from the Fortran.
ReplyDeleteI am researching PHP to see if it can be used to run programs from a web browser. If so, I'm thinking about converting the VB forms to webforms to make a web-browser the GUI instead of VB Windows.