roblem is solved (e.g. just the
laplace/poisson equation in such a domain). Such problems are very common
and a lot of people would benefit from such a tutorial.
Can anyone help in this?
Thank you very much,
Andreas Kyritsakis
--
The deal.II project is located at http://www.dealii.org/
For mailin
t where required. The manifold that is used is the one associated to
> the triangulation. You don’t need to associate it to the Mapping, since the
> mapping is used on *all* objects of the triangulation, and it will know how
> to construct the data from the underlying manifold objects.
>
>
Wolfgang,
> How does GetDP do that? Is it a global flag that is set once?
In GetDP the user defines in the input script an object called "Jacobian",
which can be different for each domain region. When setting up an integral
term in the weak formulation then, you have to specify which jacobian
Hi,
I want to use a real-to-reference-cell mapping which corresponds to
cylindrical symmetry in 2D. In other words, the integration jacobian and
the shape function gradients should contain the scale factor of the
cylindrical coordinates. I tried to do it with the following code:
QGauss<2>
Wolfgang,
Thank you very much for your prompt response.
You are right that one could just leave the mapping as a simple 2D and
change the weak formulation. However I think that it is possible to solve
an axisymmetric problem without touching the weak formulation. I have been
working for
Hello,
This is to report what I think is a bug in
GridTools::get_active_neighbors().
The following code should compile but it does not.
#include
#include
#include
#include
using namespace dealii;
template
class Test{
public:
Test(Triangulation *tria) : triangulation(triangulation),
Hi Wolfgang,
Thank you very much. Your answer was very helpful.
> You're correct -- the mapping classes don't do that. I also think that
they
> shouldn't: They have a different purpose and at least at the moment I
don't
> quite see how that could be put into what the mappings are supposed to
remained the same extremely low, which might result in unnecessary
computational effort.
I wonder whether the tolerance can be increased to something more
reasonable (e.g. 1.e-10) or there is something I am missing that suggests
such a low tolerance.
Best regards,
Andreas Kyritsakis
Thank you very much Wolfgang. Yes I would like to propose a patch. How is
it done? I am not familiar with the process.
On Thursday, May 28, 2020 at 7:31:04 PM UTC+3, Wolfgang Bangerth wrote:
>
> On 5/28/20 3:08 AM, Andreas Kyritsakis wrote:
> >
> > I have a problem with
rrent/doxygen/deal.II/classSparseDirectUMFPACK.html
>
> You might want to take a look at step 22, which uses this solver:
>
> https://www.dealii.org/current/doxygen/deal.II/step_22.html
>
> Best,
> Simon
>
> On Tuesday, June 2, 2020 at 12:04:38 PM UTC+2, Andreas Kyritsakis wrote:
>>
&g
Dear all,
I have a problem where a Poisson-like equation has to be solved again and
again in many time steps. At each timestep the LHS remains the same while
the RHS changes (slightly). My current implementation is to use the
standard SolverCG, passing the old solution as initial, which
ing of the class could
> address that issue.
>
> Best,
> Jean-Paul
>
> On 02 Jun 2020, at 12:53, Andreas Kyritsakis > wrote:
>
> Thanks a lot!!
>
> On Tuesday, June 2, 2020 at 1:21:37 PM UTC+3, Simon Sticko wrote:
>>
>> Hi,
>> a better opti
12 matches
Mail list logo
