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

[Bug] Upwards flowing systems still pour from the top #20

Open
ZoeRichter opened this issue Nov 26, 2024 · 1 comment
Open

[Bug] Upwards flowing systems still pour from the top #20

ZoeRichter opened this issue Nov 26, 2024 · 1 comment
Assignees
Labels
Status:4-In Progress This is actively being worked on by the assignee. Type:Bug Something is wrong or broken. This issue or PR is related to a bug in code.
Milestone

Comments

@ZoeRichter
Copy link
Collaborator

Describe the bug.

Problem (bug?) - Ghastly has a flag for upward flow, and that flag correctly switches the "gravity" vector to the upwards direction, but in the functions that determine the bounding box and pour regions in LAMMPS, it still does this from the top, which will not work. Upwards flow will also require adding a term for having the top surface of a core element be closed (so the pebbles don't float away).

What is the expected behavior?

It should have an insertion region at the bottom, and bounds that are expanded in the -z direction accordingly. The core_intake region being at a more positive z-direction than core_main and core_outtake is not a requirement, so the current method of "removing" the intake region to make space while pouring should still work. This also means that even when using upwards flow, the intake zone can still actually be the intake (instead of some weird interaction where the core_outtake is actually the intake because it happens to be the lowest in the z-direction).

Additional context.

Core filling currently works for downward flows.

How can this issue be closed?

Adding the above fixes so that core filling can happen for upward-flowing systems.

@ZoeRichter ZoeRichter added Status:1-New No one has claimed this issue yet. It is in need of solving. Type:Bug Something is wrong or broken. This issue or PR is related to a bug in code. labels Nov 26, 2024
@ZoeRichter ZoeRichter self-assigned this Nov 26, 2024
@ZoeRichter
Copy link
Collaborator Author

This is also where you can address the PR comment from #17 on if the scaling factors for the box bounds should be hard-coded.

@katyhuff katyhuff added Status:4-In Progress This is actively being worked on by the assignee. and removed Status:1-New No one has claimed this issue yet. It is in need of solving. labels Dec 3, 2024
@katyhuff katyhuff added this to the Prelim milestone Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status:4-In Progress This is actively being worked on by the assignee. Type:Bug Something is wrong or broken. This issue or PR is related to a bug in code.
Projects
None yet
Development

No branches or pull requests

2 participants