Hi Wolfgang,
Thank you for the suggestion. I did not think about it, but testing
statistical properties (center of mass, average velocity, total kinetic
energy) seems like a very sound idea!
If you want to see an animation of DEM done using the deal.II particle
library, you can find one on the
Hi Bruno,
We are currently working on our DEM simulation engine using deal.II particles
features. DEM lead to very chaotic systems (with positive Lyapunov exponents,
like in MD), which means that slight discrepancies in floating point numbers
can lead to exponentially different results. You
Dear all,
I hope you are well.
It is me again pestering you all with questions or looking for advice :).
We are currently working on our DEM simulation engine using deal.II
particles features. DEM lead to very chaotic systems (with positive
Lyapunov exponents, like in MD), which means that
The FiniteElementDomination logic in the codim=0 case would indeed make up
a cheap a priori check in this context.
In case a FE_Nothing has been configured to dominate, the solution should
be continuous on the interface if I understood correctly, i.e., zero on the
face. I will write a few
The problem here is that the solution is not continuous across the face of a
FE_Q and a FE_Nothing element. If a FE_Nothing is turned into a FE_Q element,
the solution is suddenly expected to be continuous, and we have no rule in
deal.II yet how to continue in the situation. In my opinion,
Hi Wolfgang,
your explanation makes indeed more sense in the context of piecewise
polynomials :)
The problem here is that the solution is not continuous across the face of
a FE_Q and a FE_Nothing element. If a FE_Nothing is turned into a FE_Q
element, the solution is suddenly expected to be
On 12/27/20 8:48 PM, Marc Fehling wrote:
2) I did not know you were trying to interpolate a FENothing element into a
FEQ element. This should not be possible, as you can not interpolate
information from simply 'nothing', and some assertion should be triggered
while trying to do so. The other
On 12/26/20 10:08 PM, amir kiani wrote:
By reading tutorials on the website of Deal.ii, I realized that using
Deal.ii directly on windows is experimentally supported.
That may no longer be an accurate description. deal.II 9.2 is used in a number
of industrial applications that run on Windows.
On 12/26/20 3:06 AM, Konrad Simon wrote:
What one can also do is just constrain one DoF to a specific value (this would
also remove rigid motion in elasticity). But think about your solution
variable: If it is in the Sobolev space H^1 then point evaluations may not be
defined for dimension
Hi Amir,
deal.II 9.1 requires c++11
deal.II 9.2 requires c++11
deal.II 9.3 will require c++14
Your only choice would be to use an older version of deal.II but I
would strongly suggest updating your compilers instead.
On Sun, Dec 27, 2020 at 12:09 AM amir kiani wrote:
>
> Hello.
> Recently I
Dear all,
I'm considering a multigrid method for the Stokes problem. I need to have
an approximation of Schur complement at each level that is represented by a
matrix-free operator.
The problem is that in case of adaptive mesh refinement MGConstrainedDoFs
assumes zero boundary condition at
11 matches
Mail list logo
