Thank you very much for your guidance.
I think that with the H curl conforming element like FeNedelec or
FeNedelecSZ, my solution vector has continuous tangential component, isn't
it?
Thus, Is there some where I can see my vector solution is discontinuous?
Can I check it by visualization?
I think
No that's fair enough.
I had thought the way I was doing it would be the equivalent of setting no
tangential stresses. I actually also did it this way as I wasn't sure how
you impose it strongly.
To impose strongly - would you just use
On 3/18/19 12:37 PM, jane@jandj-ltd.com wrote:
>
> For the u_t=0 condition, I had been imposing weak. So basically, I have
> separated a Neumann boundary condition into:
> n.[pI-2e] = (n.[pI-2e]n)n + (n.[pI-2e]t)t
> and saying that the second term on the rhs is 0 so disappears, and the first
Hello everyone!
This is deal.II newsletter #71.
It automatically reports recently merged features and discussions about the
deal.II finite element library.
## Below you find a list of recently proposed or merged features:
#7825: Add missing #ifdef DEAL_II_WITH_THREADS around tbb calls
Take a look at this PR for a few examples of usage of mesh_loop:
https://github.com/dealii/dealii/pull/7806
The function WorkStream::run
takes (a minimum of) 5 arguments:
WorkStream::run(cell, endc, cell_worker, copier, scratch, copy);
initial and final iterator, a worker function, a copier
Hi Wolfgang,
step-20: Yes indeed I do agree that that is what I am doing. I guess I'm
trying now to find out what else it could be that is producing: the correct
boundary points as in the Dirichlet condition when local_rhs=0 is done
again (overwriting), but the wrong boundary points when it
On 3/18/19 4:14 AM, Daniel Arndt wrote:
>
> VectorTools::point_value() does more or less the same you are doing above
> manually, i.e. calling GridTools::find_active_cell_around_point() and then
> initializing a FEValues object for evaluating the given finite element
> vector.
Specifically,
On 3/16/19 7:12 AM, Konrad wrote:
>
> Tried it with BDM elements but it does not work. I strongly think about
> starting to contribute to deal.ii.
I'm glad to see that you've already found the issue, but I would like to add
that I think this here would be a really good idea! :-) We are always
Jane,
> Ok, re the first step-20 bc issue, I'll have another think, but I still am
> not
> sure why then it isn't giving me the exact figure, whilst my suggestion is (I
> understand your point here and I would have said I agreed with you, but my
> implementation does work). I've verified
Similar question: How are the different loop-functions differentiated, i.e.
MeshWorker::integration_loop and MeshWorker::mesh_loop? Both are able to
loop over faces, boundaries and cells, but what are the differences here?
Thanks!
Am Dienstag, 22. Januar 2019 16:56:28 UTC+1 schrieb Bruno
Thank you, Daniel. That confirms my intuition about that. The push forward
from the ref cell to physical cells is, I found after thinking about it
again, for RaviartThomas, BDM, Nedelec elements etc not the same as a Piola
transform (which eliminates scaling but not rotation). My code works now
This did exactly what I needed. Thanks!!
On Saturday, March 16, 2019 at 5:48:14 PM UTC, Jean-Paul Pelteret wrote:
>
> There’s a function to compute the bounding box in GridTools:
>
> https://www.dealii.org/current/doxygen/deal.II/namespaceGridTools.html#ae1ec55abefa31cf001fd29d8d4d993f1
>
>
> On
Konrad,
I implemented a class derived from the Function class that evaluates
a scalar or vector shape function at a given (set of) point(s) in a
physical cell. If I check the output graphically I see that the vector
shapefunctions on the physical cell, for example for lowest order
>
> [...]
>
1. When evaluating point is on the vertex of a cell, this means that there
> should be several cells in 3D have this vertex.
> Thus, my first question is the function :
>
> const std::pair::active_cell_iterator, Point>
> cell_point =
Nicola,
-) I believe that GridIn.read_ucd appears to ignore manifold ids associated
> to the cells, it seems to me that the flag
> apply_all_indicators_to_manifold_ids does not affect the manifold id for
> the cell. This issue has never been seen because internally the material_id
> was
You may also find useful this link:
https://journals.ub.uni-heidelberg.de/index.php/ans/issue/view/2930
where the authors implement XFEM in deal.II to model interface problems.
L.
> On 18 Mar 2019, at 9:39, Daniel Arndt
> wrote:
>
> James,
>
> I am a graduate student who will be defending
James,
> I am a graduate student who will be defending in the not-too-distant
> future, and afterwards I want to remain in the research community even
> though I will be leaving academia for the foreseeable future. My research
> group has an established cohesive-zone model (CZM) code that is
17 matches
Mail list logo
