Comments (8)
The current logic is:
//TODO: The "correct" condition would be to not do the correction for compressible
// models if there are either open boundaries, or if there are boundaries
// where the prescribed velocity is so that in- and outflux do not exactly
// match
do_pressure_rhs_compatibility_modification = (material_model->is_compressible()
&&
(parameters.prescribed_velocity_boundary_indicators.size() == 0)
&&
(open_velocity_boundary_indicators.size() == 0));
And I don't understand why prescribed should be handled differently than zero boundaries. @bangerth ?
from aspect.
Hm, I need to remind me again about that as well. The issue was that we rewrite the condition
div(rho u) = 0
as
div u = b
with some fixed b. Integrating over the domain and integrating by parts yields the condition
int_Gamma u.n = int_Omega b
So, if we have (i) zero boundary conditions, (ii) tangential boundary conditions, (iii) prescribed boundary conditions that happen to be tangential as is often the case, then the left hand side is zero and we need to make sure the same is true for the right hand side -- i.e., do the modification.
On the other hand, if there is are boundaries where there is some normal flow (i.e., there are open boundaries, or prescribed boundary conditions with unknown normal conditions), then the left hand side is nonzero and we cannot do the modification.
There is one case that we probably currently handle wrongly: if the user prescribes the velocity at some part but the prescribed values happen to be tangential (a common case) then we should do the modification, but don't right now. Similarly for cases where the flow happens to be not just purely tangential, but happens to cancel when integrated over the entire boundary.
I think one can construe another case where there is normal flow but left and right hand side are not compatible. In that case one would need to adjust the right hand side so that
int_Omega b = int_Gamma normal_component_of_prescribed_velocity
I think this is what @gassmoeller is referring to, right?
We could decide to just always do the rhs modification by always computing the boundary integral. Is this what you suggest, Rene?
Does anyone
from aspect.
It seems like the end of your comment got truncated somehow. Anyway, if we would do the compatibility modification in any case with the integral of the normal velocity that would solve my problems very well (my models are in the described category that we currently handle wrong).
Maybe I missed a mathematical detail, but I just wonder what then happens in cases, where somebody prescribes a completely senseless boundary condition (like inflow at any boundary)? Would the compatibility correction you described then result in a solution that has no meaning, or would the solver still get a convergence error?
from aspect.
As long as you have a compressible model, inflow on all boundaries is completely valid from a physical point of view -- you just increase the pressure and compress the material some more :-)
I do wonder what happens to our formulation, though. We make the assumption that the pressure is dominated by the hydrostatic pressure. I imagine that in the situation you describe you just get garbage.
In any case, I think doing the modification in all cases where there is no open/traction boundary makes sense but we need to compute the boundary integral, at least over all boundaries with prescribed velocity.
from aspect.
Ok I guess, if you prescribe such boundary velocities you will notice soon enough that something is odd.
Yes then the boundary integral seems like a good way. Do you have some time to implement it before the release?
from aspect.
Otherwise I would take a look at it, when I have some more time, but can not promise on when that would be.
from aspect.
I'm afraid I won't. Let's postpone the issue until after the release.
from aspect.
Is merged and done. I will close the issue.
from aspect.
Related Issues (20)
- remove old deal.II support leftovers HOT 1
- Surface stress output with interpolated & higher order visu output fails HOT 4
- unity build compile issues HOT 2
- add Frank-Kamenetski eq in manual HOT 1
- Poor nonlinear solver performance for VEP rheology + particles + continous compositional fields HOT 4
- defect correction + AMG convergence issue HOT 5
- flexible compositional fields: mix CG/DG and different degrees
- ctest GENERATE_REFERENCE_OUTPUT with failing tests
- Warning in rheology/composite_visco_plastic.cc
- Always set up both DEBUG and RELEASE targets, utilize EXCLUDE_FROM_ALL. HOT 1
- Use TARGET_INCLUDE_DIRECTORIES instead of INCLUDE_DIRECTORIES.
- BoundaryTractions::Interface has unused member geometry_model. HOT 1
- perplex data in .dat should use ASCII data instead HOT 1
- weighted BFBT Preconditioner HOT 6
- Splitting particle worlds
- Cannot compile main on cluster HOT 3
- broken cookbooks/mantle_convection_with_continents_in_annulus/ HOT 4
- broken cookbooks/tian_parameterization_kinematic_slab/
- move AdvectionField out of Simulator
- Not converging cookbooks
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aspect.