[phreeqc] parallelization acceleration

[zhichengcai]

Hi, for modeling calcite precipitation during evaporation and dissolution in a wet season, the simulation needs more than 10 hours with the following KINETICS settings:
```
...
-steps 2592000 in 60 steps    # 30 days in 60 steps # 30*24*60*60 = 2592000
-step_divide 1e-4
-runge_kutta 6
...
```
Is there any way to accelerate the execution by utilizing multiple CPUs? Currently, one Phreeqc program only computes in one CPU.

(1.) I checked the manual and version release notes, but there are no parallel computation settings for Phreeqc. Only five appearances for word "parallel": four relating to "diffusion parallel", and the other one mentioned "parallel processing" but this "parallel processing" is relating to multiple Phreeqc programs running according to the context, not the parallel techniques for acceleration. Also, this mention is a kind reminder for using PUT or GET I/O operations.

(2.) There was one mention for parallelization in 1999, however, no more parallelization computing was mentioned after that for Phreeqc in status update report:

``` (https://wwwbrr.cr.usgs.gov/projects/GWC_coupled/phreeqc/status.htm)
December 15, 1999: Parallel PHREEQC
A parallel version of PHREEQC that uses calls to MPI is in the works. So far, only the LAM version of MPI has been tested. Factors of 5-10 speedups have been attained for transport simulations on a LAN with up to 20 Sun and Linux machines. Further testing and debugging are needed.
```

(3.) I also checked on this forum, and there is only one mention for Phreeqc parallelization in a post called "openMP" in 2014 (https://phreeqcusers.org/index.php/topic,55.msg110.html#msg110). Unfortunately, the reply indicates there was no such feature for Phreeqc at that time.

Are there any ways to parallel Phreeqc running?

(PS: My current simulation is not a reactive transporter. That can use PhreeqcRM for parallelization.)

[dlparkhurst]

No, there is no parallelized version of batch PHREEQC. Probably half the execution time is spent in the linear equation optimization solver. So, a factor of two might be possible, but the arrays are relatively small, say 100x20, and parallel linear equation solvers are not that good on small arrays (or large arrays for that matter).

From what you have shown, if you can avoid step_divide 1e-4, the simulation should run faster. Even if it is necessary in the early times of the calculation, you may be able to split the calculation so that later times do not require it.

You should also try -cvode, it may be faster or considerably slower than Runge Kutta, but worth investigating.

Most importantly, make sure that you define the data block INCREMENTAL_REACTIONS true before or in the simulation with KINETICS. The default is INCREMENTAL_REACTIONS false, which means that it integrates from 0 to 0.5 days, 0 to 1 day, 0 to 1.5 days, etc. It is a "feature" of the way the program developed. Setting INCREMENTAL_REACTIONS to true, the integration proceeds from 0 to 0.5, 0.5 to 1, 1 to 1.5, etc. If the initial time is the difficult part of the integration, it may run about 60 times faster.

[zhichengcai]

Thank you!
After setting the INCREMENTAL_REACTIONS true, it goes much faster now. :)