Restrictive size limitations of COSMO calculations

[godotalgorithm]

There is size-limiting logic preventing large MOPAC calculations with COSMO turned on (EPS keyword) that is unnecessarily aggressive. Often, the same large molecule can be calculated with MOZYME but not MOPAC because of this limiter. This limiter was added at some point in MOPAC's past because of COSMO calculations running out of memory, but it is likely to be too aggressively calibrated for modern machines and needs to be adjusted.

[flatstik]

Then again, with really large proteins, you usually have to have more than +150gb of ram available which begs the question I asked in this thread

[godotalgorithm]

We are interested in learning more about how MOPAC is being used for very large systems. MOPAC has historically been stress tested mostly by user activity and feedback, most of which has been focused on small and moderately sized molecules. What sort of protein is using a memory footprint of 150GB, and is this in a conventional MOPAC calculation or with MOZYME? While MOZYME's computational cost is not strictly linear-scaling, its memory footprint is supposed to be strictly linear-scaling. It would take quite a large protein to hit a 150GB memory footprint, unless there is some unexpected memory bottleneck emerging, either in the main components of MOPAC/MOZYME or in its COSMO implementation. Can you share an example that is entering into this regime of memory usage, either a MOPAC input file or a PDB entry?

[flatstik]

I was trying to use PM7 with COSMO on approximately 9000 atom containing protein model. I'll try to search the files tomorrow and edit this post with attachment of the input file

Edit: account terminated in the computing cluster used. Will do fresh testing next month.

[godotalgorithm]

The size limiter has been removed by #51, and this error message now only appears when COSMO actually runs out of memory.

It is worth noting here that MOZYME and conventional MOPAC calculations use different implementations of COSMO. The MOPAC implementation has a much larger memory footprint and is also likely to be slower, which is why this error message was relevant in the first place. In principle, the faster, lower-memory COSMO implementation could be adapted to work with conventional MOPAC calculations, but this will require a nontrivial amount of development effort and isn't a high priority. Practically, the speed differences aren't going to be very big, so this issue probably won't be a priority until/unless users start reporting this memory limitation as a problem.