> The idea of a helpful interface to phreeqe is fantastic. But because of my difficulty using it, I'm compelled to make some comments. > After several years away from phreeqe, I was surprised by how much effort it is taking me to re-learn the key word concept and overwhelmed by the effort that it takes > me to learn how to use the windows front-end. I assume you are using version 2, not version 1 (http://wwwbrr.cr.usgs.gov/projects/GWC_coupled/phreeqc). > I failed to simply re-create the input file for example 1 using the on-line help, interface intuition, and geochemistry experience. A simple step-by-step tutorial would be really helpful to show just how files are created. For example, I cannot determine how the words "as HCO3" appear after alkalinity in "ex1" short of typing them in myself. But that cannot be right since that would require my absolute and precise knowledge of the syntax - kind of defeats the utility and beauty of the windows front-end. In other words, my problem is the interface, not my geochemistry. I fear that it will take me days and days to learn and experiment with phreeqe before I am comfortable with applying a real problem. It is really difficult to determine how people respond to cues in interactive programs. We have tried to make things as easy as possible, while maintaining the generality of PHREEQC. If we hard code the options for the gram formulae, then addition of a new element will not be handled consistently. A column labeled "as/gfw" is available to change the conversion factor for an element concentration from mass to moles and the "Description of Input" box gives more details, with some specific information about alkalinity. (Embedded image moved to file: pic24590.gif) > Also, while I appreciate interest in protecting the original code integrity and formats, I feel that forcing a user to deal directly with "key words" and expressions like "as HCO3" bogs down the user with syntax, jargon, and unnecessary typing. Windows programming allows for a far superior way of isolating the user from such details. Simply "checking" a checkbox labeled "as HCO3" as opposed to checking the one marked "as CaCO3" could invisibly place the necessary code language into the input file. A good user/geochemist should use his/her skill to know what boxes to check and not what syntax to use. Also, the user can always look at the input file, but if you think about it, that shouldn't be necessary and "messing" with that file directly can potentially lead to errors that are hard to find except by very experienced users. Our experience has been that people use a combination of the screen input and editing. It has definitely required more effort in development to allow the direct editing of files, so maybe that was a mistake on our part. I certainly get frustrated if I have to go through several screens to correct a single typo. You can enter and edit all of the data (we're still working on a few keywords, but will hopefully finish before too long) with the screen input which will preclude any syntax errors, so the choice is yours. I hope you appreciate all of the Windows programming that has been included, some of which is quite difficult to get to work seamlessly throughout the program. > Consider a modflow analogy: modflow used to be tedious mostly because it required such direct user attention to syntax and columns and columns of cell data values. Then, excellent windows software appeared in the 90's which virtually eliminated such headaches and modeling became a virtual laboratory for experimental hydrogeology and not a data entry and syntax nightmare. Modflow with all of its packages is very much "keyword" driven. I think it is a very similar approach to organizing a wide variety of process information. > Again, I am struck by the excellent front-end for phreeqe, but I think it needs to go a few steps further to be a real user-friendly tool. Is there any interest or support in my position on this topic? "Excellent" is perhaps not the right word considering your comments. I am committed to producing the best interface that we can put together. In the future, I am considering the use of wizards for common tasks. However, I want to finish the remaining keywords of the interface, so currently, I do not support your position on this topic. This is the second interface that we have developed. Version 1 was much clunkier but perhaps clearer in some parts of the design. It was so tedious, that I did not use it. I think version 2 is a major improvement, to the point that I actually use some of the screens as opposed to simply typing the keywords directly. I think it makes sense to finish at the current level and decide what people have the most trouble with. Your input is welcome and will be considered in further improving the interface. David David Parkhurst (dlpark@xxxxxxxx) U.S. Geological Survey Box 25046, MS 413 Denver Federal Center Denver, CO 80225
Description: GIF image
Please note that some U.S. Geological Survey (USGS) information accessed through this page may be preliminary in nature and presented prior to final review and approval by the Director of the USGS. This information is provided with the understanding that it is not guaranteed to be correct or complete and conclusions drawn from such information are the sole responsibility of the user.
Any use of trade, product, or firm names in this publication is for descriptive purposes only and does not imply endorsement by the U.S. Government.
The URL of this page is:
Last modified: $Date: 2005-09-13 21:04:21 -0600 (Tue, 13 Sep 2005) $
Visitor number 1992 since Jan 22, 1998.