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

Are Flamelet objects generators? #24

Open
michael-a-hansen opened this issue Sep 13, 2022 · 0 comments
Open

Are Flamelet objects generators? #24

michael-a-hansen opened this issue Sep 13, 2022 · 0 comments

Comments

@michael-a-hansen
Copy link
Collaborator

michael-a-hansen commented Sep 13, 2022

We need to clarify the use of state within the flamelet class. For certain things like steady solves we simply use Flamelet instances once and keep rebuilding new ones (build_adiabatic_slfm_library), while in other cases we build a Flamelet and "keep it around" for a while (nonadiabatic, nonstrained library builders). This is a subtle distinction but it's important. We've redesigned around FlameletSpec, which is a persistent container of data required to set up a flamelet calculation. Should we reduce the Flamelet class to functions that return FlameletResult instances that are similarly persistent? It's not ideal to have an ambiguous mix between single-use and persistent data structures, which I think Flamelet falls into right now.

This is relevant to arc length continuation. Do we treat that like transient flamelets where a Flamelet instance provides the entire trajectory, or because we are continuating over the dissipation rate in arc length, do we have to make new Flamelet instances (in which case it wouldn't make sense for Flamelet to have an arc length member function).

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

No branches or pull requests

1 participant