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

Parallelism assumes direct west.h5 file access #37

Open
jdrusso opened this issue Nov 4, 2022 · 1 comment
Open

Parallelism assumes direct west.h5 file access #37

jdrusso opened this issue Nov 4, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@jdrusso
Copy link
Owner

jdrusso commented Nov 4, 2022

Currently, some parallelized sections of msm_we still assume they'll have direct access to the west.h5 files being analyzed.

For example, taking the discretization: in do_stratified_ray_discretization, I pass an iteration to the remote worker, and the remote worker is responsible for retrieving the data.

This was an intentional decision, to avoid having to send lots of data. However, this means we assume direct access to the west.h5 files... This prevents you from using a remote cluster for Ray work.

To me, it seems like the options are:

  • Copy all the west.h5 files to the remote worker, maybe in the restart plugin? Ray supports this in init via runtime_env argument, but it has pretty conservative limits on file size.
    This has the drawback of requiring a large file copy.
  • Send iteration data directly, rather than having each worker read it.
    This, on the other hand, has the drawback of requiring lots of data to be sent over the network.
@jdrusso jdrusso added the enhancement New feature or request label Nov 4, 2022
@jdrusso jdrusso changed the title Refactor parallelism to not rely on direct west.h5 file access Parallelism assumes direct west.h5 file access Nov 4, 2022
@jdrusso
Copy link
Owner Author

jdrusso commented Nov 8, 2022

This is partially addressed in #39 which provides an explicit base path to west.h5 files. As long as the same path is available on the remote workers, everything is fine.

This is in contrast to assuming the relative path is available, which depends entirely on the working directory of your Ray workers (and probably isn't generally true)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant