Error: NULL pointer returned from malloc or realloc

[phuongthanh.hd.1993]

Dear all,

I have missed one error that "Error: NULL pointer returned from malloc or realloc" during running reactive transport simulation.
This is the first time I got this error.
Anybody got the same error?
What should I do to solve this problem?

Thank you

Best regards,

[dlparkhurst]

That is something that we need to fix. I suspect you have made a mistake in your input file, but it has triggered a problem in our code.

Please attach your input file, and I will see if there is a work around for you, and will trap the error in the next version of the code.

[phuongthanh.hd.1993]

Dear,

Thank you for your respond, I guess that the problem comes from the large number of cell in transport simulation (some of my input files have  around 130000 cells, I cannot attach)
I cannot reduce the number of cell.
I have attached my input file bellow, please help me to see it.

Many thanks.

Best regards,

[dlparkhurst]

I think you ran out of memory. My suggestion is to run the program with the batch version of PHREEQC in a powershell window. You can download the batch version from the web site. It is normally installed in c://Program Files/USGS/Phreeqc...

Two executables are available in the bin directory. If you are not plotting, use the Release version.

You have been using Phreeqc for Windows, which may have considerable overhead related to the graphical user interface, both in memory and processing time. The batch version should avoid the overhead, and is a 64-bit version (not sure if Phreeqc for Windows is 64 or 32), and it is version 3 (with enhancements and bug fixes), whereas Phreeqc for Windows still uses version 2.

Further, your run generates a 50 Gb output file (not the selected output), which is probably too big to process anyway. Consider using PRINT; -reset false to avoid generating the output file, while maintaining output to the selected output file.

Unless you require -cvode, consider using the default Runge Kutta kinetics integrator. It will run much faster.

Finally, I am guessing you are doing some type of timing or run-time comparison, but for numerical accuracy, the number of cells you are using is overkill. "The purpose of computing is insight, not numbers.", Richard Hamming.

[phuongthanh.hd.1993]

Dear Dr. Parkhurst,

Many thanks for your support.
I got your point, it works much faster.

Thank developer team.

Best regards,
Melinda