Hi Bruno,
Sure, I can try making a PR this week.
Best,
Alex
On Sunday, June 27, 2021 at 9:36:50 p.m. UTC+2 blais...@gmail.com wrote:
> I most likely copied this mistake from the regular Cylinder and did not
> think of it when I coded the subdivided cylinder.
> Alex, if you feel comfortable,
I have been trying to construct a system that is small (a total length of
1e-5 m) with the subdivided cylinder grid generator. However, I have been
having trouble with the boundary indicators. I wanted to set my own
boundaries, and because there is no colorize option (it defaults to setting
I am working with a mesh generated from subdivided_cylinder, and am
wondering whether the area and volume should be assumed to match that of a
true cylinder, or if it only converges to that when many refinements are
made. I would like to calculate the total energy of the system by
integrating
I am also unable to access the website, although it is specifically the
documentation pages that are down.
Best,
Alex
On Monday, June 14, 2021 at 2:16:08 a.m. UTC+2 corbin@gmail.com wrote:
> Hello everyone,
>
> It seems dealii.org is experiencing some problems or is down (I'm on the
>
Hi Wolfgang,
I tried a quadratic element, and was able to reduce the number of degrees
of freedom for the same level of convergence by another order of magnitude.
Thanks!
Best,
Alex
On Friday, June 11, 2021 at 3:34:08 p.m. UTC+2 Wolfgang Bangerth wrote:
> On 6/11/21 4:04 AM, Alex Cumberwo
g linear element. I encountered
> the same large error when comparing it with Abaqus with FE_Q(1). But the
> error came down with less grids when I used higher finite element
> FE_Q(2). I remember the deflection of beam is a cubic function of
> coordinate. You may try that see if it improves
had to set
>
> export XTPE_LINK_TYPE=dynamic
> export CRAYPE_LINK_TYPE=dynamic
>
> before the installation. You can try and see if anything similar is
> happening.
>
> Regards,
> Vachan
>
> On Mon, 7 Jun 2021 at 22:34, Wolfgang Bangerth
> wrote:
>
>> On 6/7/21
look for the static version of the
library.
Best,
Alex
On Monday, June 7, 2021 at 6:11:52 p.m. UTC+2 Wolfgang Bangerth wrote:
> On 6/7/21 10:02 AM, Alex Cumberworth wrote:
> > The cause of this particular issue actually appears to be some symlinks
> to the
> > mpi include di
still compiling, I have passed all previous points where I had errors.
Best,
Alex
On Monday, June 7, 2021 at 5:41:24 p.m. UTC+2 Wolfgang Bangerth wrote:
> On 6/7/21 8:41 AM, Alex Cumberworth wrote:
> > I noticed that I attached the error file for 9.2, and that the source of
> th
NDIALS or Trilinos using the same MPI
> implementation as the other one?
>
> Best,
> Daniel
>
> Am Mo., 7. Juni 2021 um 09:26 Uhr schrieb Alex Cumberworth <
> alexanderc...@gmail.com>:
>
>> Hi Bruno,
>>
>> I repeated the compilation with deal.ii 9.3 an
On Friday, June 4, 2021 at 5:24:03 p.m. UTC+2 Alex Cumberworth wrote:
> Hi Vachan,
>
> Thanks for your response. This actually works. However, I still end up
> with an incompatibility of the MPI configuration between the Trilinos
> library and deal.ii. I ended up compiling Trili
n maybe making this change will do the job. You may even try
> manually adding the full path in the cmake module file as a hint.
>
> Hope this helps
> Vachan
>
> On Thu, 3 Jun 2021 at 15:07, Alex Cumberworth
> wrote:
>
>> Hello,
>>
>> The file does exist and
Hello,
The file does exist and is readable. If I set a manual include flag it is
able to find it:
CMAKE_CXX_FLAGS_DEBUGRELEASE
-I/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0/include
then it is able to get past this point. From the output in my previous
message, it seems that cmake is
. UTC+2 Wolfgang Bangerth wrote:
> On 5/27/21 4:25 AM, Alex Cumberworth wrote:
> >
> > However, trilinos is loaded as a module, and even with the fresh
> configuration
> > it is unable to find the header. Even with
> >
> > //Path to a file.
> >
> SAC
Wolfgang Bangerth wrote:
> On 5/26/21 11:17 AM, Alex Cumberworth wrote:
> > It seems that the issues stem from not setting the include directories
> > properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as
> I
> > mentioned in my previous response,
,
Alex
On Monday, May 24, 2021 at 5:22:57 p.m. UTC+2 Wolfgang Bangerth wrote:
> On 5/21/21 11:03 AM, Alex Cumberworth wrote:
> >
> > I don't really see how this can be, as this version of the compiler
> fully
> > supports C++11. I also tried setting the flag
t deal.II picks the compiler correctly but it looks like
> the stl library is too old. What version of libstdc++ is installed on
> the system?
>
> Best,
>
> Bruno
>
> Le ven. 21 mai 2021 à 13:41, Alex Cumberworth
> a écrit :
> >
> > Hi Bruno,
> >
Hi Bruno,
>From the output when I run a fresh configuration:
-- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /opt/ohpc/pub/compiler/gcc/9.3.0/bin/c++
-- Check for working CXX compiler:
Hello,
I am trying to compile deal.II, version 9.2, on CentOS 8.3.2011 (the last
version). I have gcc 9.3.0, which is relatively recent. However, when I run
cmake, I end up with the following message:
The current combination of compiler and C++ version flag is missing some
features of the
h forward its
> first index (i.e. compute P = F.S) and then you can get to computing F_{t}
> as stated above.
>
> I hope that helps clear things up a bit.
>
> Best,
> Jean-Paul
>
>
> On 11. May 2021, at 12:46, Alex Cumberworth
> wrote:
>
> Hello,
>
>
hysics_1_1Transformations.html#aa82925b742c3708f625a48a7abc440bc>
> .
> Maybe you could try to use that and see if you get the result that you’re
> looking for.
>
> Best,
> Jean-Paul
>
> On 4. May 2021, at 12:36, Alex Cumberworth
> wrote:
>
> Hello,
>
> I would like to calculate
I ended up getting it working, so in case anyone else is interested in
doing something similar, I have attached updated versions of the previous
scripts. I further modified set_periodicity_constraints so that it can take
a function to set the inhomogeneity based on the values of the two support
Hi Jean-Paul,
Thanks for the response. I realize I should have specified that the values
of the inhomogeneities that I would like to use are the differences in the
two points that are being glued together. This means that when I set the
inhomogeneity for a degree of freedom, I actually need
I need to implement periodic boundary constraints with inhomogeneities.
>From reading through the documentation and source code of the library, it
seems that to do this I will need to modify the set_periodicity_constraints
function in the dof_tools_constraints.cc file to also add an
Thanks for the information. Unfortunately I am more interested in the
second case, so I will look around for examples of the mortar
element/master slave approach.
Alex
On Thursday, December 17, 2020 at 2:11:14 a.m. UTC+1 Wolfgang Bangerth
wrote:
>
> > I am considering switching to deal.II
25 matches
Mail list logo
