Abel from the Netherlands

[Abel]

Hi all,

I'm a process engineer working for Vitens.

Vitens is the largest drinking water company in The Netherlands. Annually we deliver 350 million m3 from 100 small and large groundwater treatment plants of top quality drinking water to 5.6 million customers. One of our main focus points the coming years is using advanced chemical, physical and hydraulic models and (big) data analysis to further improve our treatment and distribution process performance. Although originally developed for geochemical modeling, Phreeqc has proven to be a very valuable tool for drinking water modeling as well.

One thing I'm working on at this moment is extending the IPhreeqc module to allow direct access to solution properties such as pH, SC and speciation. Another thing I'm doing is linking Phreeqc with EPANET, something that will, in time, allow us to simulate entire treatment plants complete with control valves, pumps, reservoirs, chemical dosing points, etc.

If you're interested, my ongoing work on adapting the IPhreeqc module to our needs can be found here: https://github.com/AbelHeinsbroek/VIPhreeqc

I hope to be able to share some of my EPANET related work in a later stage if you're interested!

[dlparkhurst]

Pretty cool, both the application to drinking water and the extensions to IPhreeqc.

(We took a look at your code, which looks nice; however, did see a problem with the const char * return values. The string pointed to goes out of scope, possibly resulting in a bad pointer if the memory gets reused. You may want to use string_hsave to store the string and return the pointer. The string pointed to by const char * will then persist until the IPhreeqc module is destroyed.)

[Abel]

Thank you for the feedback David! I am indeed running into out-of-scope problems with the const char * return values. My C++ knowledge is still rudimentary at best but I'll see if I can fix the problems.

I'm glad you like the work I'm doing to extend IPhreeqc. Having direct access to some of the solution properties allows us to use the Phreeqc engine to it's full potential in our dynamic models. See for example the attached image of a very simple treatment process simulated using EPANET coupled with Phreeqc.

Are you interested in collaborating on bringing back some of the added functionality to the core IPhreeqc distribution, or do you prefer us to continue working on our own separate VIPhreeqc product?

[dlparkhurst]

I think for now, I would rather you have a separate development for a couple reasons. The first is that the Phreeqc class is used in the reaction module PhreeqcRM, and it is important to try to minimize memory if it is applied to millions of cells. (Although some option to include or remove the extra storage would certainly be possible.) The second is purely the amount of effort it would take to add many new methods in Fortran, C, C++, and R with the associated documentation. Looks like C is your platform, and it is much simpler (and reasonable) to limit the scope to a more manageable project.

Just as a suggestion, if you can make a new VIPhreeqc class that inherits from IPhreeqc, it may be easier to keep the two project separate, as well as update to new versions of PHREEQC and IPhreeqc without having to modify the IPhreeqc code. I think you will need to have VIPhreeqc be a friend of Phreeqc, but we can add that to the PHREEQC code base if that is the way you go.