Jump to content
Geochemist's Workbench Support Forum


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Sven

  • Rank

Profile Information

  • Gender
  1. Using the 'alter' command in react is a very convenient way to test the impact of thermodynamic data variability on modelling results. Unfortunately the command seems to be restricted to equilibrium constants. Is there any way to use the command for Pitzer ion interaction coefficients as well?
  2. Hi Brian Your suggested solutions works well. But I have a high number of consecutive react runs (some 100 or 1000) that I have to evaluate automatically. Therefore I have to get along with the information in the output text file because the binary gtp output files are not directly accessible. I think a workaround for me would be to add a specific commentary line for each mineral in the database containing its full name. When the output text files are read the short names are replaced by the long name found in the database.
  3. In the react output files in the section "Mineral staturation states" the only the first 15 characters of a mineral name are printed. Longer mineral names are cut. In some cases it is necessary to have longer names, for example if dealing with solid phases of more complex nature such as clays and other naturally occuring multi-element phases. Examples: K8(HCO3)4(CO3)2:3H2O (20 characters) GreenRust(Na,SO4) (17 characters) Fe(OH)2.65Cl0.35 (16 characters) In order to make them distinguishable in the react output file, cryptic short names have to be used in the database which in turn appear in all dialogs and diagrams. It would be preferable if the full mineral names could be printed under "Mineral Saturation states" or if at least perhaps 25 characters could be used. Or is there any option to get around this problem?
  4. Hi Brian, you are correct. It is possible to kill the process started by ShellExecute (WinAPI of course although I sometime feel like an Win-Ape when working with WinAPI) after a certain time. But with a script that contains several hundred or so runs, killing the process (that fails to complete run #257 for example) would mean not to execute the remaining runs (258, 259, ...) in the script. An alternative would be to execute React for every single run (with an individual script for each run). But that approach would be considerably slower since React would have to be reloaded every time. A way to handle the problem would be to write code that - continuously checks which runs have been completed - kill React if one run takes too long - remove from the script all parts that have already bee processed and - restart React with the shortened script
  5. Hi Brian Thank you for your reply and for passing the request. My controlling program works as follows: It generates a single React script for a number or consecutive runs and then executes React.exe via a WinAPE ShellExecute procedure with the script as a parameter. Once started I have no control over the execution of the script. Only when React has completely executed the script control is given back to my controlling program. A workaround would be to kill React.exe if the total execution time seems to be too long, check which runs have been done and pass a reduced script to a newly called React. Another principal possibility would be of course to use the plug-in feature to have direct control over React. But I would have to write a Delphi wrapper for GWBs C++ DLLs, which I try to avoid. Best regards Sven
  6. I am currently using GWB 9 (React) for uncertainty analyses meaning that I start some hundred or thousand runs with a single script. Sometimes one or another run within this number is proceeding endlessly. In my specific case the maximum number of iterations was exceeded so that the step size was reduced. Since this happened several times the step size became so small that no significant reaction progress took place any more. I have fixed this problem by increasing itmax to 1000. But in another case even that didn't help. Is there any possibility to automatically kill a run when for example a maximum number of steps or the absolute time used for a single run is exceeded? I know that I can manually kill a run from the GWB menu, but if you are running 10000 calculations or so in a queue, it would be more economic to have the code doing that for you.