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

[OptApp] Refactoring Implicit Filters #12186

Merged
merged 38 commits into from
Mar 20, 2024
Merged

Conversation

sunethwarna
Copy link
Member

@sunethwarna sunethwarna commented Mar 14, 2024

📝 Description
This PR refactors implicit filters in OptApp. It also adds a another "shape" filter type which automatically detects to use "general_vector" or "bulk_surface_shape" depending on the entities present in the filtering model part (Requird for the FilterFactory).

🆕 Changelog

  • Added ModelPartUtils::GenerateModelPart to create surface helmholtz elements from the conditions. The existing python implementation was slow in adding nodes because it needs to sort the nodal container everytime it adds a node according to the ids. This implementation adds all the nodes at once in c++, so the sorting is only done once, hence faster than the master implemenation.
  • Removed ImplicitFilterUtils::AssignProperties, and uses the ReadMaterialUtility from the core for the same.
  • Added abstract methods to HelmholtzSolverBase to make the design more pythonic, and modular.
  • Removed ImplicitFilterUtils::CalculateNodeNeighbourCount and uses the ExpressionUtils::ComputeNumberOfNeighbourElements. This was duplicated in expressions, so now unifies the implementation.
  • HelmholtzVectorSolver now implements bare minimum, and uses ConnectivityPreserveModeler to create helmholtz elements
  • HelmholtzScalarSolver now implements bare minimum, and uses ConnectivityPreserveModeler to create helmholtz elements
  • Introduced HelmholtzShapeSolver which is intended to solve for the shape. (It needs to be a seperate solver as it is doing different things depending on the model part.)
  • HelmholtzSolverBase::GetFilterType is removed. Now there is no need to branch in the HelmhotlzAnalysis depending on the fitler type.
  • A logic was added (NUMBER_OF_SOLVERS_USING_NODES) to detect whether the same origin model part is used by multiple filters. This is important, if we are to use implicit filters on two scalar quantity controllers on the same origin model part, then it will use the same nodes for both filters. So this new variable will tell us to apply the BCs every time or not.
  • Added tests fir tge bew HelmholtzShapeSolver

@sunethwarna sunethwarna self-assigned this Mar 14, 2024
@sunethwarna sunethwarna added Applications Optimization related to OptApp C++ Python Refactor When code is moved or rewrote keeping the same behavior labels Mar 14, 2024
@sunethwarna sunethwarna changed the title [OptApp] Refactoring Implciit Filters [OptApp] Refactoring Implicit Filters Mar 18, 2024
Copy link
Contributor

@RezaNajian RezaNajian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sunethwarna thanks for the works

@sunethwarna sunethwarna merged commit 08507c7 into master Mar 20, 2024
11 checks passed
@sunethwarna sunethwarna deleted the optapp/filter/refactor_implicit branch March 20, 2024 07:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Applications C++ Optimization related to OptApp Python Refactor When code is moved or rewrote keeping the same behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants