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

Implement Stacey boundary condition #130

Open
SouzaEM opened this issue Oct 24, 2024 · 2 comments
Open

Implement Stacey boundary condition #130

SouzaEM opened this issue Oct 24, 2024 · 2 comments
Assignees

Comments

@SouzaEM
Copy link
Collaborator

SouzaEM commented Oct 24, 2024

Implement Stacey boundary condition for isotropic elastic wave propagator

@SouzaEM SouzaEM self-assigned this Oct 24, 2024
@SouzaEM
Copy link
Collaborator Author

SouzaEM commented Oct 25, 2024

With the implementation of Stacey boundary condition, spyro will have three options of boundary conditions (correct me if I'm missing other implementations that should be addressed):

  • PML
  • Clayton-Engquist A1
  • Stacey

I think we need to define how the absorbing boundary condition should be structured to allow configuring each of the boundary conditions in a clear way for the user. My initial proposal is to introduce a nested dictionary structure to separate parameters that are specific to a absorbing boundary condition method. For example:

d = {
    "absorving_boundary_conditions":  {
        "damping_type": "PML", # or local (we may introduce other options later, such as hydrid)
        "PML": {
            "exponent": 2,
            "cmax": 4.7,
            "R": 1e-6,
            "pad_length": 0.25,
        },
        "local": {
            "type": "Stacey", # or CE_A1 (Clayton-Engquist A1) - in the future we may also add Higdon, Lysmer-Kuhlemeyer, etc for completeness
            "dt_scheme": "backward", # or "central" (finite-difference scheme for velocity calculation)
        },
}

Do you have any thoughts?

PS: the key "absorving_boundary_conditions" is misspelled in the code. I can fix it during the development of this issue.

@Olender
Copy link
Collaborator

Olender commented Oct 25, 2024

I agree with your nested dictionary approach for structuring boundary condition parameters; this layout seems clean and flexible, particularly for introducing new boundary options in the future.

Thanks for catching the spelling issue as well!

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

2 participants