Dear Quế-Hương Trần ,

If the model is correct, perhaps the problem is mdrun. It is not parallelizing the simulation.

Dear Quế-Hương Trần ,

Normally, the more atoms in your system, the more computational cost is required.

Thus, first, you need to optimize the system size, balancing the accuracy and your computational resource.

1. How big your protein or solute is? If the solute is large, the number of solvents will be huge. Based on the difference of number atoms between solvent and total, I expect the solute is not too big.

2. Then, how big the box is? I suggest creating the box length around the length of the solute + 2 nm (the distance between the solute and the box is 1 nm). The distance between the solute from the different boxes should be larger than the cut-off to avoid artificial interaction. The larger distance is better, but needs more computational cost, of course. You can define it by gmx editconf ...... -d 1

If the number of solvents is still too many, you don't have any choice except improve the computational resource by using more cores or using GPU, or both.

Best regards,

Dear Quế-Hương Trần

I noticed that the model features over 100,000 atoms. In general, PDB formats do not support more than 99,999. It is a file type limitation. See if the numbering has restarted from 100,000 atoms.

Dear Huong Tran,

With gromacs you can use GPU to make the computational time lower. It will compute the non-bonded interactions. To enable this option add -nb gpu to your command line. Moreover, as Khabib Khumaini suggested, look at your box size to see if it is not to large compare to the solute.