Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restart wont't work on large meshes #80

Open
yungyuc opened this issue Nov 30, 2013 · 8 comments
Open

Restart wont't work on large meshes #80

yungyuc opened this issue Nov 30, 2013 · 8 comments

Comments

@yungyuc
Copy link
Member

yungyuc commented Nov 30, 2013

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)


When restart from a large mesh SOLVCON fails with out any error messages.
Increasing the number of mpi processes does not help.
Each solvcon.dump.solver files is about 900MB
the solvcon.dump.case.obj file was about 50GB
The system that I ran it on has ~30GB of memory per node.

It might be useful to decrease the size of the solvcon.dump.case.obj files or split up the loading.


@yungyuc
Copy link
Member Author

yungyuc commented Nov 30, 2013

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


Does this happen in the 0.1.2+ version of SOLVCON?

@yungyuc
Copy link
Member Author

yungyuc commented Dec 22, 2013

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


@david_b Do you have further update for this issue?

@yungyuc
Copy link
Member Author

yungyuc commented Jan 31, 2014

Original comment by David Bilyeu (BitBucket: david_b, GitHub: david_b):


Not much, I couldn't get Solvcon to run on the large memory nodes. I cannot get gcc or python to compile on it and the default versions are too old for Solvcon to work. I have a ticket in for them to provide an updated version of gcc but it could take some time before it gets installed.

@yungyuc
Copy link
Member Author

yungyuc commented Feb 1, 2014

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


As we discussed in hangout, I think the first step to resolve this issue is
to create a tiny test case to study how we can shink the dump file. 50GB
is just unacceptable.

@yungyuc
Copy link
Member Author

yungyuc commented May 21, 2014

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


@david_b any update on this issue? A small, reproducing test case would be the next step.

@yungyuc
Copy link
Member Author

yungyuc commented Jul 12, 2014

Original comment by David Bilyeu (BitBucket: david_b, GitHub: david_b):


Sorry, I don't have any update on this issue. I was unable to compile the
required version of gcc on the large memory node and am waiting for the
system admins to install a newer version.
This issue should be reproducible if you try to load a restart file that is
larger than the available memory. If this is run on a singe computer then
virtual memory would need to be used during the simulation. I have done a
simulation that required virtual memory before so I don't know how python
would handle it. Another possibility would be to limit the amount of
available memory on the system, e.g. lode a large file into paraview.

David

@yungyuc
Copy link
Member Author

yungyuc commented Jul 13, 2014

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


@david_b I think I may be able to try that on AWS.

@yungyuc
Copy link
Member Author

yungyuc commented Nov 25, 2014

Original comment by Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc):


v0.1.3 will focus on a sequential run. Let's postpone this to later releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant