is the issue solved now? I have compiled your code with the current version
of deal.II and it works.
On Monday, 8 June 2020 09:56:21 UTC+2, A.Z Ihsan wrote:
> Oops, i was wrong. I followed the deal.ii 9.2.0 tutorial meanwhile in my
> local deal.ii version is 9.1.
Oops, i was wrong. I followed the deal.ii 9.2.0 tutorial meanwhile in my
local deal.ii version is 9.1.
There is a couple different implementation in terms of FESeries::Fourier.
On Friday, June 5, 2020 at 12:25:47 PM UTC+2, A.Z Ihsan wrote:
> Hi Peter,
> thank you for the answer. Actually i
This is not a problem. Members of the deal.II user group are very friendly
and very helpful. I was helped tremendously by a lot of people (JP
Pelteret, Wolfgang, Luca) when I started.
Feel free to try and help others when you become more accustomed.
PS : If you must know, I am
Indeed! Christoph, you seem to be right!
Feel free to create a pull request on GitHub for this inconsistency! We
will help you if you need some assistance! Amazing that there are still
errors in the first tutorials although - probably - all deal.II user have
had a look at these...
Thank you Praveen,
that solved my problem. After fixing the issue with the boundary id
things made sense. Is there a particular reason that in 1D the boundary
points are labeled in a different manner than in 2+ D?
PS. deal ii team. In the documentation on step 3 + 4 it states that the
yes, it is solved now. Thanks Peter.
In deal.ii 9.2.0 the implementation detail of FESeries::Fourier constructor
can take the first argument of std::vector, meanwhile in
deal.ii 9.1 only unsigned int.
On Monday, June 8, 2020 at 10:10:18 AM UTC+2, peterrum wrote:
Dear deal.II community,
For a distributed implementation, we would like to broadcast packed data
For the beginning, we would like to understand how the serialize function
for packing an object is working in the sense of the deal.II way, before it
is getting more complicated.
You are correct: We opted for a more versatile approach in transforming
solutions into Fourier or Legendre series with deal.II 9.2. Glad you
figured it out!
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
The problem is that the size of `auto buffer =
dealii::Utilities::pack(r1);` is not the same on all processes, which is a
requirement if you use `MPI_Bcast`. My suggestion would to split the
procedure into two steps: 1) bcast the size on rank 1; 2) bcast the actual
I've never used this functionality of git but I think I just posted a
pull-request describing this minor issue.
Wouldn't it be easier to change the documentation on the tutorials
website or is that done through Git, too?
PS. My experience with Git is rather limited although I
I hope you are doing well.
In my endless quest for robust mesh generation of hex meshes using GMSH, I
have managed to come up with a very robust strategy to generate hex-only
My only issue (which is a major one) is that this implies that my
decomposition from tet to hex adds
On 6/8/20 10:22 AM, Bruno Blais wrote:
Would any of you have a suggestion on how best to achieve the deformation of
the nodes to match the manifold?
I suspect that this depends a lot on how exactly your manifold is given. You
need some projection onto the manifold. If you used IGES CAD
I tried using the VectorTools::project idea from step-25. However, my code
fails to compile, and I could not decipher the errors and do not know how to
fix this problem (have been stuck for a while).
The attached code tries to implement Step-52 (but for 1D), with homogenous
What you could also do is to turn compression off.
On Monday, 8 June 2020 14:19:25 UTC+2, peterrum wrote:
> Dear Maurice,
> The problem is that the size of `auto buffer =
> dealii::Utilities::pack(r1);` is not the same on all processes, which is a
> requirement if you use
Mail list logo