It will be the drive where the results are saved to (Study Properties; Results Folder).
Run space is greater than results space. Particularly large problems will generate temp files with extension .101, .102, .103 etc. that cycle around and write over themselves. It is not uncommon for me to have about 20Gb of temp files generating a results (.cwr) file of 2Gb.
Model size is not directly proportional to disk space in my experience. Though yes, obviously the larger the model the larger the space required.
Are these questions for helping to spec a new workstation, or for other troubleshooting?
I currently have only a 147 GB hard drive. It seems that if I add a 300 GB hard drive and push the non SW stuff and the page file onto it (perhaps also the results folder) then I should be OK for a while AND I won't upset the SW installation.
I can test this in the short term by allocating the results folder to the 70 GB partition which I cleared out for the page file (that was necessary to achieve meshing).
You have been very helpful Dave.
For what it's worth, my setup uses a 128Gb drive for Windows / SolidWorks / Abaqus / MS Office etc., and then I have a second "Analysis" hard disk on to which my part files and results are saved. Data storage/archiving is then handled with a network drive once I have completed a task.
Each drive is a 15k rpm mechanical drive. I experience no measurable performance loss having SW installed on one drive and having the parts/results written to another.
Moving the Results folder to a partition with more space solved the error message problem.
I saved the mesh and tried the solver several times, but failed to get a result.
Studying the Windows Task Manager display and the HDD LED, made me suspect that the HDD was thrashing.
Googling for others experience with pagefile found an explanation of page faults.
Looking again at Task Manager I saw that after 11 hours of solving, the only parameter that was incrementing was page faults. It seems that with 8 GB of RAM and 30 GB of pagefile, I was going nowhere because the system could not get into RAM the various pages required to complete the solution.
So whereas I was inclined to buy more disk for temporary files because I could never have enough RAM for the biggest job I might attempt, I now understand why RAM is a better purchase.
If I find I still need temporary filespace then SSD looks to be the answer because it appears that the 4K cluster size matches the 4K page size, whereas HDD cluster size of 512K is a legacy of sequential (apps & docs) data files where there was no problem in bringing more data than you asked for because it would probably be the next lot you wanted anyway (so we had cache). Reducing HDD cluster size increases the overhead of latency and seek, thus tearing your trousers
How do you see this?
Honestly, faffing around with Page File size is beyond my experience. I run 12Gb of RAM in my main workstation and this is sufficient for almost all of my jobs. For any jobs needing more than 12Gb, I switch to the shared FEA-specific workstation with 32Gb of RAM. This has proven to be sufficient for all jobs so far.
If I were you I'd just bite the bullet and go nuts with RAM purchasing rather than messing around with swapping to Page Files.