Re: [deal.II] Re: Function to output stress and strain
Hi Denis, Thank you for the pointer! This is very helpful. The below is my understanding (and please let me know if I am wrong): 1. If we do the L2 projection over a domain of elements, then it smooths the stress jumps in the sense of integration. The stress would be continuous over the domain; 2. Or, if we do the L2 projection over single elements (or, we focus on elements on the boundaries between the domains in #1), there will still be jumps over the boundaries. This sometimes is desirable; we can then choose our own method to assign to the node (e.g. peak stress). Thanks, Shawn On Friday, November 4, 2016 at 4:08:00 AM UTC-7, Denis Davydov wrote: > > Hi Lisa, > > > > On 4 Nov 2016, at 11:54, Lisa Collins > wrote: > > > > Thanks for the replies. > > The problem I am facing has two parts: > > > > 1- In deal ii, how to calculate stress at nodes based on stress at Gauss > points? Stress at nodal points is not continues. Is there any averaging > function to calculate stress at nodal points? > > Well, that’s exactly my reply above ;-) You can do an L2 projection from a > discontinuous function (defined by values at quadrature points) to a > continuous FE space. This could also be understood as some averaging. > > Cheers, > Denis. > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Gradient of the shape function wrt natural coordinate system?
Exactly what I was looking for! Thank you so much Professor Bangerth. Have a great one, Shawn On Sun, Oct 14, 2018 at 1:47 PM Wolfgang Bangerth wrote: > On 10/14/2018 11:57 AM, Yuxiang Wang wrote: > > > > While I can use the shape_grad function to get the gradient of the shape > > function with respect to the real cell coordinates, would there be a way > to > > get the shape_grad with respect to the reference natural coordinates? > For > > example, for shell element (that I'm working on), I have the global > > coordinates (x, y, z) for a point and also a natural coordinate system > (r, s, t). > > > > One possibility is that I can use the chain rule and the jacobian matrix > to > > get that value, but it'll be very computationally inefficient. Could > anyone > > please help? > > I think you are asking for the *unmapped* shape functions as they are > defined > on the reference cell. That's something you can get from the finite > element > itself via the >FiniteElement::shape_grad() > function or its implementation in derived classes. > > The gradient of the shape functions mapped to a particular cell in a mesh > can > be obtained via FEValues::shape_grad(), which I think is what you are > referring to above. > > Best > W. > > -- > > Wolfgang Bangerth email: bange...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "deal.II User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/dealii/-s1Dc9sbPE4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > dealii+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Yuxiang "Shawn" Wang, PhD yw...@virginia.edu +1 (434) 284-0836 -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Gradient of the shape function wrt natural coordinate system?
Dear all, While I can use the shape_grad function to get the gradient of the shape function with respect to the real cell coordinates, would there be a way to get the shape_grad with respect to the reference natural coordinates? For example, for shell element (that I'm working on), I have the global coordinates (x, y, z) for a point and also a natural coordinate system (r, s, t). One possibility is that I can use the chain rule and the jacobian matrix to get that value, but it'll be very computationally inefficient. Could anyone please help? Best, Shawn -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Is "-- Configuring incomplete, errors occurred!" OK?
Thank you so much Matthias! Sorry that I thought it would just compile without Trilinos in that case. I did: cmake -DCMAKE_INSTALL_PREFIX=/mnt/e/dealii/abq1d/installed -DDEAL_II_WITH_TRILINOS=OFF And it ran perfectly. Best, Shawn On Fri, Oct 12, 2018 at 4:59 PM Matthias Maier wrote: > You have a faulty trilinos installation, in particular the project > configuration file > > /usr/lib/x86_64-linux-gnu/cmake/Trilinos/TrilinosConfig.cmake > > is broken (See lines 355 - 2432 of your output file). You can either > > * disable Trilinos for the time being by configuring with >-DWITH_TRILINOS=OFF, > > * or compile and install a Trilinos version that has a sane >configuration file and configure with >-DWITH_TRILINOS=ONF -DTRILINOS_DIR="...", >(where you replace "..." with a path to your trilinos installation. > > Best, > Matthias > > > > On Fri, Oct 12, 2018, at 17:36 CDT, Yuxiang Wang < > yuxiang.shawn.w...@gmail.com> wrote: > > > Thank you Prof. Bangerth for the response! > > > > Actually I kept that window open so I still have the original message. I > > looked into it and saw quite a few optional packages not found, but I > > thought that would be fine. Other than that, I wasn't able to pin-point > > where the problem is. I have attached the entire message sent from cmake > as > > attached. I'd really appreciate any feedback! > > > > Best, > > Shawn > > > > On Fri, Oct 12, 2018 at 3:19 PM Wolfgang Bangerth < > bange...@colostate.edu> > > wrote: > > > >> On 10/10/2018 03:33 PM, Yuxiang Wang wrote: > >> > > >> > -- Configuring incomplete, errors occurred! > >> > See also > >> "/mnt/e/dealii/abq1d/dealii/build/CMakeFiles/CMakeOutput.log". > >> > > >> > > >> > > >> > Is this OK and just indicating that there are external dependencies > not > >> > met (which is OK for me)? My intent is not to build deal.ii with all > >> > dependencies (I have candi for that), but just to build a minimal > build. > >> > I have also attached the CMakeOutput.log and CMakeError.log, just in > >> case. > >> > >> No, these errors are not good. > >> > >> I can't see from the files that you attached what the error really is. > >> But if you run the cmake command again and carefully scroll through the > >> output produced before the "Configuring incomplete" message, you should > >> be able to find which place produced the error message, and that should > >> help figure out why that happened. > >> > >> Best > >> W. > >> > >> > >> -- > >> > >> Wolfgang Bangerth email: > bange...@colostate.edu > >> www: > http://www.math.colostate.edu/~bangerth/ > >> > >> -- > >> The deal.II project is located at http://www.dealii.org/ > >> For mailing list/forum options, see > >> https://groups.google.com/d/forum/dealii?hl=en > >> --- > >> You received this message because you are subscribed to a topic in the > >> Google Groups "deal.II User Group" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/dealii/qfXQ8ZcM89Y/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > >> dealii+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > > > -- > > Yuxiang "Shawn" Wang, PhD > > yw...@virginia.edu > > +1 (434) 284-0836 > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "deal.II User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/dealii/qfXQ8ZcM89Y/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > dealii+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Yuxiang "Shawn" Wang, PhD yw...@virginia.edu +1 (434) 284-0836 -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Can GridIn read 3D quad mesh?
Thank you Jean-Paul! Let me open an issue at GitHub. Best, Shawn On Thursday, October 4, 2018 at 1:45:27 AM UTC-7, Jean-Paul Pelteret wrote: > > Dear Yuxiang, > > Yes, indeed the co-dimension 2 case is not supported as of yet. However, I > think that there is sufficient robustness in the current implementation of > the Abaqus grid reader that it would be possible to implement this without > too much difficulty. The three places that one would probably have to focus > one's attention on are the definition of the “element” here > <https://github.com/dealii/dealii/blob/master/source/grid/grid_in.cc#L3317>, > the boundaries here > <https://github.com/dealii/dealii/blob/master/source/grid/grid_in.cc#L3368>, > and then face indices in this function > <https://github.com/dealii/dealii/blob/master/source/grid/grid_in.cc#L3368> > (this > last part should be completely trivial). If you want to try to add this > functionality then you could open up an issue > <https://github.com/dealii/dealii/issues/new> in the GitHub repository > and we could discuss this further over there. We would appreciate this > contribution! > > Best, > Jean-Paul > > On 04 Oct 2018, at 08:54, Yuxiang Wang > wrote: > > Hi Jean-Paul, > > Thank you again for the fix and sorry to bother again. I wonder that, > would you think it'd be easy to have spacedim = 3 and dim = 1 implemented? > This would be very useful for beam elements (e.g. Timoshenko beams). I saw > here that: > > > https://github.com/jppelteret/dealii/blob/4d6c06d4ebae1b342861d2cf937f0ce3bb331d5b/source/grid/grid_in.cc#L960 > > This scenario would currently raise an error. Would you think that would > be easy? I would be happy to provide sample files if that would be helpful. > > Best, > Shawn > > On Friday, September 21, 2018 at 12:09:47 AM UTC-7, Jean-Paul Pelteret > wrote: >> >> That's so fast! >> >> >> Well, it was an easy fix so we got lucky there. But the test case you >> provided was really useful, so we appreciate you providing that. >> >> Thank you Jean-Paul :) >> >> >> You’re quite welcome. >> >> Best, >> Jean-Paul >> >> On Thursday, September 20, 2018 at 1:20:46 AM UTC-7, Jean-Paul Pelteret >> wrote: >>> >>> Dear Shawn, >>> >>> No, its fine. I see that the changes weren’t as drastic as I thought >>> they’d be, so I think that the boundary ID assignment will work out of the >>> box (I’d forgotten that someone else had already done much of the work >>> necessary to support codim-1). >>> >>> I’ve made a patch to add this functionality. See here: >>> https://github.com/dealii/dealii/pull/7217 >>> Thank a lot for the grids and the minimal test case! >>> >>> Best, >>> J-P >>> >>> On 20 Sep 2018, at 08:11, Yuxiang Wang wrote: >>> >>> Oh I see! Thank you for explaining. My guess would be that the ABAQUS >>> equivalent is "node set". Please let me know if you'd like me to try that! >>> >>> Best, >>> Shawn >>> >>> On Wed, Sep 19, 2018 at 10:00 PM Jean-Paul Pelteret >>> wrote: >>> >>>> Hi Shawn, >>>> >>>> >>>> Thank you for your help! I'd love to provide the mesh. Please let me >>>> know whether the attached one would work. >>>> >>>> >>>> You’re welcome. This second mesh is perfect. I’ll let you know when >>>> I’ve submitted a patch that allows this grid to be read in. >>>> >>>> For the boundary coloring - could you please elaborate on what that >>>> means? I wasn't aware that ABAQUS has such a coloring feature but it could >>>> be me not knowing this though. >>>> >>>> >>>> This means assigning some boundary ID’s (in all of the documentation we >>>> call it “colouring”). Cubit allows one to do this, but I don’t know about >>>> ABAQUS itself (I would have thought it would be possible). I’ll try to >>>> modify the input file you supplied, which should be possible since the >>>> geometry is simple enough. >>>> >>>> Best, >>>> Jean-Paul >>>> >>>> >>>> On Tue, Sep 18, 2018 at 10:57 PM Jean-Paul Pelteret >>>> wrote: >>>> >>>>> Dear Shawn, >>>>> >>>>> The GridIn::read_abaqus() function is currently not equipped to deal >>>>> with the codimension 1 case. I might be
Re: [deal.II] Can GridIn read 3D quad mesh?
Hi Jean-Paul,
Thank you again for the fix and sorry to bother again. I wonder that, would
you think it'd be easy to have spacedim = 3 and dim = 1 implemented? This
would be very useful for beam elements (e.g. Timoshenko beams). I saw here
that:
https://github.com/jppelteret/dealii/blob/4d6c06d4ebae1b342861d2cf937f0ce3bb331d5b/source/grid/grid_in.cc#L960
This scenario would currently raise an error. Would you think that would be
easy? I would be happy to provide sample files if that would be helpful.
Best,
Shawn
On Friday, September 21, 2018 at 12:09:47 AM UTC-7, Jean-Paul Pelteret
wrote:
>
> That's so fast!
>
>
> Well, it was an easy fix so we got lucky there. But the test case you
> provided was really useful, so we appreciate you providing that.
>
> Thank you Jean-Paul :)
>
>
> You’re quite welcome.
>
> Best,
> Jean-Paul
>
> On Thursday, September 20, 2018 at 1:20:46 AM UTC-7, Jean-Paul Pelteret
> wrote:
>>
>> Dear Shawn,
>>
>> No, its fine. I see that the changes weren’t as drastic as I thought
>> they’d be, so I think that the boundary ID assignment will work out of the
>> box (I’d forgotten that someone else had already done much of the work
>> necessary to support codim-1).
>>
>> I’ve made a patch to add this functionality. See here:
>> https://github.com/dealii/dealii/pull/7217
>> Thank a lot for the grids and the minimal test case!
>>
>> Best,
>> J-P
>>
>> On 20 Sep 2018, at 08:11, Yuxiang Wang wrote:
>>
>> Oh I see! Thank you for explaining. My guess would be that the ABAQUS
>> equivalent is "node set". Please let me know if you'd like me to try that!
>>
>> Best,
>> Shawn
>>
>> On Wed, Sep 19, 2018 at 10:00 PM Jean-Paul Pelteret
>> wrote:
>>
>>> Hi Shawn,
>>>
>>>
>>> Thank you for your help! I'd love to provide the mesh. Please let me
>>> know whether the attached one would work.
>>>
>>>
>>> You’re welcome. This second mesh is perfect. I’ll let you know when I’ve
>>> submitted a patch that allows this grid to be read in.
>>>
>>> For the boundary coloring - could you please elaborate on what that
>>> means? I wasn't aware that ABAQUS has such a coloring feature but it could
>>> be me not knowing this though.
>>>
>>>
>>> This means assigning some boundary ID’s (in all of the documentation we
>>> call it “colouring”). Cubit allows one to do this, but I don’t know about
>>> ABAQUS itself (I would have thought it would be possible). I’ll try to
>>> modify the input file you supplied, which should be possible since the
>>> geometry is simple enough.
>>>
>>> Best,
>>> Jean-Paul
>>>
>>>
>>> On Tue, Sep 18, 2018 at 10:57 PM Jean-Paul Pelteret
>>> wrote:
>>>
>>>> Dear Shawn,
>>>>
>>>> The GridIn::read_abaqus() function is currently not equipped to deal
>>>> with the codimension 1 case. I might be able to find some time to look at
>>>> this in the next few days though. In addition to the mesh file that you’ve
>>>> already given us, may you please construct and give us a fully structured
>>>> grid in codimension 1 (so something like a rectangle warped in the third
>>>> dimension) that also has some boundary colouring? That would help a great
>>>> deal with implementing this feature, and would also ensure that the
>>>> assignment of boundary ID’s is possible.
>>>>
>>>> Best,
>>>> Jean-Paul
>>>>
>>>> On 19 Sep 2018, at 01:38, Yuxiang Wang wrote:
>>>>
>>>> Prof. Bangerth,
>>>>
>>>> Thank you for the prompt response! Yes please find attached the minimal
>>>> program. The main body is pretty short (see below), modified from step-49.
>>>> Please let me know if you cannot reproduce it!
>>>>
>>>> ```
>>>> int main ()
>>>> {
>>>> Triangulation<2, 3> triangulation;
>>>>
>>>> GridIn<2, 3> gridin;
>>>> gridin.attach_triangulation(triangulation);
>>>> std::ifstream f("mesh.inp");
>>>> gridin.read_abaqus(f);
>>>>
>>>> GridOut gridout;
>>>> std::ofstream fout("mesh.vtu");
>>>> gridout.write_vtu(triangulation, fout);
>>>> }
>>>>
>>>> ```
>>>>
>>>>
>>>> Shawn
>>>>
>>>> O
Re: [deal.II] Can GridIn read 3D quad mesh?
That's so fast! Thank you Jean-Paul :)
Shawn
On Thursday, September 20, 2018 at 1:20:46 AM UTC-7, Jean-Paul Pelteret
wrote:
>
> Dear Shawn,
>
> No, its fine. I see that the changes weren’t as drastic as I thought
> they’d be, so I think that the boundary ID assignment will work out of the
> box (I’d forgotten that someone else had already done much of the work
> necessary to support codim-1).
>
> I’ve made a patch to add this functionality. See here:
> https://github.com/dealii/dealii/pull/7217
> Thank a lot for the grids and the minimal test case!
>
> Best,
> J-P
>
> On 20 Sep 2018, at 08:11, Yuxiang Wang > wrote:
>
> Oh I see! Thank you for explaining. My guess would be that the ABAQUS
> equivalent is "node set". Please let me know if you'd like me to try that!
>
> Best,
> Shawn
>
> On Wed, Sep 19, 2018 at 10:00 PM Jean-Paul Pelteret > wrote:
>
>> Hi Shawn,
>>
>>
>> Thank you for your help! I'd love to provide the mesh. Please let me know
>> whether the attached one would work.
>>
>>
>> You’re welcome. This second mesh is perfect. I’ll let you know when I’ve
>> submitted a patch that allows this grid to be read in.
>>
>> For the boundary coloring - could you please elaborate on what that
>> means? I wasn't aware that ABAQUS has such a coloring feature but it could
>> be me not knowing this though.
>>
>>
>> This means assigning some boundary ID’s (in all of the documentation we
>> call it “colouring”). Cubit allows one to do this, but I don’t know about
>> ABAQUS itself (I would have thought it would be possible). I’ll try to
>> modify the input file you supplied, which should be possible since the
>> geometry is simple enough.
>>
>> Best,
>> Jean-Paul
>>
>>
>> On Tue, Sep 18, 2018 at 10:57 PM Jean-Paul Pelteret > > wrote:
>>
>>> Dear Shawn,
>>>
>>> The GridIn::read_abaqus() function is currently not equipped to deal
>>> with the codimension 1 case. I might be able to find some time to look at
>>> this in the next few days though. In addition to the mesh file that you’ve
>>> already given us, may you please construct and give us a fully structured
>>> grid in codimension 1 (so something like a rectangle warped in the third
>>> dimension) that also has some boundary colouring? That would help a great
>>> deal with implementing this feature, and would also ensure that the
>>> assignment of boundary ID’s is possible.
>>>
>>> Best,
>>> Jean-Paul
>>>
>>> On 19 Sep 2018, at 01:38, Yuxiang Wang >> > wrote:
>>>
>>> Prof. Bangerth,
>>>
>>> Thank you for the prompt response! Yes please find attached the minimal
>>> program. The main body is pretty short (see below), modified from step-49.
>>> Please let me know if you cannot reproduce it!
>>>
>>> ```
>>> int main ()
>>> {
>>> Triangulation<2, 3> triangulation;
>>>
>>> GridIn<2, 3> gridin;
>>> gridin.attach_triangulation(triangulation);
>>> std::ifstream f("mesh.inp");
>>> gridin.read_abaqus(f);
>>>
>>> GridOut gridout;
>>> std::ofstream fout("mesh.vtu");
>>> gridout.write_vtu(triangulation, fout);
>>> }
>>>
>>> ```
>>>
>>>
>>> Shawn
>>>
>>> On Tue, Sep 18, 2018 at 4:28 PM Wolfgang Bangerth >> > wrote:
>>>
>>>> On 09/18/2018 03:18 PM, Yuxiang Wang wrote:
>>>> >
>>>> > Thank you for the pointer! I changed my code as you suggested and it
>>>> finished
>>>> > running.
>>>>
>>>> Great!
>>>>
>>>>
>>>> > However, when I opened the output file (mesh.vtu), the 3D mesh was
>>>> projected
>>>> > to a 2D plane of z=0, and lost its 3D features. Was that expected
>>>> behavior?
>>>>
>>>> No. Are you saying that if you read a mesh, then immediately output it
>>>> again,
>>>> that the z-coordinate is lost? If that's correct, then that's a bug and
>>>> it
>>>> would be nice to have a small program and input file that demonstrates
>>>> this.
>>>>
>>>> Best
>>>> W.
>>>>
>>>> --
>>>>
>>>> Wolfgang Bangerth email:
Re: [deal.II] Can GridIn read 3D quad mesh?
Oh I see! Thank you for explaining. My guess would be that the ABAQUS
equivalent is "node set". Please let me know if you'd like me to try that!
Best,
Shawn
On Wed, Sep 19, 2018 at 10:00 PM Jean-Paul Pelteret
wrote:
> Hi Shawn,
>
>
> Thank you for your help! I'd love to provide the mesh. Please let me know
> whether the attached one would work.
>
>
> You’re welcome. This second mesh is perfect. I’ll let you know when I’ve
> submitted a patch that allows this grid to be read in.
>
> For the boundary coloring - could you please elaborate on what that means?
> I wasn't aware that ABAQUS has such a coloring feature but it could be me
> not knowing this though.
>
>
> This means assigning some boundary ID’s (in all of the documentation we
> call it “colouring”). Cubit allows one to do this, but I don’t know about
> ABAQUS itself (I would have thought it would be possible). I’ll try to
> modify the input file you supplied, which should be possible since the
> geometry is simple enough.
>
> Best,
> Jean-Paul
>
>
> On Tue, Sep 18, 2018 at 10:57 PM Jean-Paul Pelteret
> wrote:
>
>> Dear Shawn,
>>
>> The GridIn::read_abaqus() function is currently not equipped to deal with
>> the codimension 1 case. I might be able to find some time to look at this
>> in the next few days though. In addition to the mesh file that you’ve
>> already given us, may you please construct and give us a fully structured
>> grid in codimension 1 (so something like a rectangle warped in the third
>> dimension) that also has some boundary colouring? That would help a great
>> deal with implementing this feature, and would also ensure that the
>> assignment of boundary ID’s is possible.
>>
>> Best,
>> Jean-Paul
>>
>> On 19 Sep 2018, at 01:38, Yuxiang Wang
>> wrote:
>>
>> Prof. Bangerth,
>>
>> Thank you for the prompt response! Yes please find attached the minimal
>> program. The main body is pretty short (see below), modified from step-49.
>> Please let me know if you cannot reproduce it!
>>
>> ```
>> int main ()
>> {
>> Triangulation<2, 3> triangulation;
>>
>> GridIn<2, 3> gridin;
>> gridin.attach_triangulation(triangulation);
>> std::ifstream f("mesh.inp");
>> gridin.read_abaqus(f);
>>
>> GridOut gridout;
>> std::ofstream fout("mesh.vtu");
>> gridout.write_vtu(triangulation, fout);
>> }
>>
>> ```
>>
>>
>> Shawn
>>
>> On Tue, Sep 18, 2018 at 4:28 PM Wolfgang Bangerth
>> wrote:
>>
>>> On 09/18/2018 03:18 PM, Yuxiang Wang wrote:
>>> >
>>> > Thank you for the pointer! I changed my code as you suggested and it
>>> finished
>>> > running.
>>>
>>> Great!
>>>
>>>
>>> > However, when I opened the output file (mesh.vtu), the 3D mesh was
>>> projected
>>> > to a 2D plane of z=0, and lost its 3D features. Was that expected
>>> behavior?
>>>
>>> No. Are you saying that if you read a mesh, then immediately output it
>>> again,
>>> that the z-coordinate is lost? If that's correct, then that's a bug and
>>> it
>>> would be nice to have a small program and input file that demonstrates
>>> this.
>>>
>>> Best
>>> W.
>>>
>>> --
>>>
>>> Wolfgang Bangerth email: bange...@colostate.edu
>>> www:
>>> http://www.math.colostate.edu/~bangerth/
>>>
>>> --
>>> The deal.II project is located at http://www.dealii.org/
>>> For mailing list/forum options, see
>>> https://groups.google.com/d/forum/dealii?hl=en
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "deal.II User Group" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/dealii/Erk7pxwTEj4/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> dealii+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Yuxiang "Shawn" Wang, PhD
>> yw...@virginia.edu
>> +1 (434) 284-0836
>>
>> --
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see
>> https://groups.google.com/d/forum/dea
Re: [deal.II] Can GridIn read 3D quad mesh?
Hi Jean-Paul,
Thank you for your help! I'd love to provide the mesh. Please let me know
whether the attached one would work.
For the boundary coloring - could you please elaborate on what that means?
I wasn't aware that ABAQUS has such a coloring feature but it could be me
not knowing this though.
[image: image.png]
Best,
Shawn
On Tue, Sep 18, 2018 at 10:57 PM Jean-Paul Pelteret
wrote:
> Dear Shawn,
>
> The GridIn::read_abaqus() function is currently not equipped to deal with
> the codimension 1 case. I might be able to find some time to look at this
> in the next few days though. In addition to the mesh file that you’ve
> already given us, may you please construct and give us a fully structured
> grid in codimension 1 (so something like a rectangle warped in the third
> dimension) that also has some boundary colouring? That would help a great
> deal with implementing this feature, and would also ensure that the
> assignment of boundary ID’s is possible.
>
> Best,
> Jean-Paul
>
> On 19 Sep 2018, at 01:38, Yuxiang Wang
> wrote:
>
> Prof. Bangerth,
>
> Thank you for the prompt response! Yes please find attached the minimal
> program. The main body is pretty short (see below), modified from step-49.
> Please let me know if you cannot reproduce it!
>
> ```
> int main ()
> {
> Triangulation<2, 3> triangulation;
>
> GridIn<2, 3> gridin;
> gridin.attach_triangulation(triangulation);
> std::ifstream f("mesh.inp");
> gridin.read_abaqus(f);
>
> GridOut gridout;
> std::ofstream fout("mesh.vtu");
> gridout.write_vtu(triangulation, fout);
> }
>
> ```
>
>
> Shawn
>
> On Tue, Sep 18, 2018 at 4:28 PM Wolfgang Bangerth
> wrote:
>
>> On 09/18/2018 03:18 PM, Yuxiang Wang wrote:
>> >
>> > Thank you for the pointer! I changed my code as you suggested and it
>> finished
>> > running.
>>
>> Great!
>>
>>
>> > However, when I opened the output file (mesh.vtu), the 3D mesh was
>> projected
>> > to a 2D plane of z=0, and lost its 3D features. Was that expected
>> behavior?
>>
>> No. Are you saying that if you read a mesh, then immediately output it
>> again,
>> that the z-coordinate is lost? If that's correct, then that's a bug and it
>>
>> would be nice to have a small program and input file that demonstrates
>> this.
>>
>> Best
>> W.
>>
>> --
>>
>> Wolfgang Bangerth email: bange...@colostate.edu
>> www: http://www.math.colostate.edu/~bangerth/
>>
>> --
>> The deal.II project is located at http://www.dealii.org/
>> For mailing list/forum options, see
>> https://groups.google.com/d/forum/dealii?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/dealii/Erk7pxwTEj4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> dealii+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Yuxiang "Shawn" Wang, PhD
> yw...@virginia.edu
> +1 (434) 284-0836
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/Erk7pxwTEj4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Yuxiang "Shawn" Wang, PhD
yw...@virginia.edu
+1 (434) 284-0836
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Job-1.inp
Description: Binary data
Re: [deal.II] Re: Can GridIn read 3D quad mesh?
Prof. Bangerth,
Thank you for the prompt response! Yes please find attached the minimal
program. The main body is pretty short (see below), modified from step-49.
Please let me know if you cannot reproduce it!
```
int main ()
{
Triangulation<2, 3> triangulation;
GridIn<2, 3> gridin;
gridin.attach_triangulation(triangulation);
std::ifstream f("mesh.inp");
gridin.read_abaqus(f);
GridOut gridout;
std::ofstream fout("mesh.vtu");
gridout.write_vtu(triangulation, fout);
}
```
Shawn
On Tue, Sep 18, 2018 at 4:28 PM Wolfgang Bangerth
wrote:
> On 09/18/2018 03:18 PM, Yuxiang Wang wrote:
> >
> > Thank you for the pointer! I changed my code as you suggested and it
> finished
> > running.
>
> Great!
>
>
> > However, when I opened the output file (mesh.vtu), the 3D mesh was
> projected
> > to a 2D plane of z=0, and lost its 3D features. Was that expected
> behavior?
>
> No. Are you saying that if you read a mesh, then immediately output it
> again,
> that the z-coordinate is lost? If that's correct, then that's a bug and it
> would be nice to have a small program and input file that demonstrates
> this.
>
> Best
> W.
>
> --
>
> Wolfgang Bangerth email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/Erk7pxwTEj4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Yuxiang "Shawn" Wang, PhD
yw...@virginia.edu
+1 (434) 284-0836
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace dealii;
int main ()
{
Triangulation<2, 3> triangulation;
GridIn<2, 3> gridin;
gridin.attach_triangulation(triangulation);
std::ifstream f("mesh.inp");
gridin.read_abaqus(f);
GridOut gridout;
std::ofstream fout("mesh.vtu");
gridout.write_vtu(triangulation, fout);
}
mesh.inp
Description: Binary data
##
# CMake script for the step-1 tutorial program:
##
# Set the name of the project and target:
SET(TARGET "step-49")
# Declare all source files the target consists of:
SET(TARGET_SRC
${TARGET}.cc
# You can specify additional files here!
)
# Usually, you will not need to modify anything beyond this point...
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
FIND_PACKAGE(deal.II 8.0 QUIET
HINTS ${deal.II_DIR} ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
)
IF(NOT ${deal.II_FOUND})
MESSAGE(FATAL_ERROR "\n"
"*** Could not locate deal.II. ***\n\n"
"You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to
cmake\n"
"or set an environment variable \"DEAL_II_DIR\" that contains this path."
)
ENDIF()
DEAL_II_INITIALIZE_CACHED_VARIABLES()
PROJECT(${TARGET})
DEAL_II_INVOKE_AUTOPILOT()
mesh.vtu
Description: Binary data
Re: [deal.II] Re: Can GridIn read 3D quad mesh?
Hi Professor Bangerth, Thank you for the pointer! I changed my code as you suggested and it finished running. However, when I opened the output file (mesh.vtu), the 3D mesh was projected to a 2D plane of z=0, and lost its 3D features. Was that expected behavior? Shawn On Tuesday, September 18, 2018 at 1:56:19 PM UTC-7, Wolfgang Bangerth wrote: > > On 09/18/2018 02:40 PM, Yuxiang Wang wrote: > > > > Thank you for your help! I just tried a code snippet (modified step-49) > below > > and it does not work, either when I set the dim=2 or dim=3. > > If you want to use quadrilateral (2d) meshes embedded in 3d, then you need > to use >Triangulation<2,3> >GridIn<2,3> > etc. > > The 2 is the dimension of cells, the 3 the dimension of the space in which > they live. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Re: Can GridIn read 3D quad mesh?
Oh and another detail - the mesh is not really 2D mesh because the four nodes of a quad element may not be co-planar. Therefore, there does not exist a transform that can reduce the mesh to 2D. Shawn On Monday, September 17, 2018 at 12:07:43 PM UTC-7, Daniel Arndt wrote: > > Shawn, > > If I understand correctly you want to read a 2D mesh embedded in a > three-dimensional space. > Which mesh format are you interested in? > At least, GridIn::read_ucd and GridIn::read_msh should be able to do that. > > If you experience problems, we like to here about that as well. > > Best, > Daniel > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Can GridIn read 3D quad mesh?
Hi Daniel,
Thank you for your help! I just tried a code snippet (modified step-49)
below and it does not work, either when I set the dim=2 or dim=3.
```
int main ()
{
Triangulation<2> triangulation;
GridIn<2> gridin;
gridin.attach_triangulation(triangulation);
std::ifstream f("mesh.inp");
gridin.read_abaqus(f);
GridOut gridout;
std::ofstream fout("mesh.vtu");
gridout.write_vtu(triangulation, fout);
}
```
The complete code is attached at the end of this email. If you don't mind,
could you help provide any guesses in what potentially went wrong?
Shawn
On Mon, Sep 17, 2018 at 12:07 PM Daniel Arndt <
daniel.ar...@iwr.uni-heidelberg.de> wrote:
> Shawn,
>
> If I understand correctly you want to read a 2D mesh embedded in a
> three-dimensional space.
> Which mesh format are you interested in?
> At least, GridIn::read_ucd and GridIn::read_msh should be able to do that.
>
> If you experience problems, we like to here about that as well.
>
> Best,
> Daniel
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/Erk7pxwTEj4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Yuxiang "Shawn" Wang, PhD
yw...@virginia.edu
+1 (434) 284-0836
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
##
# CMake script for the step-1 tutorial program:
##
# Set the name of the project and target:
SET(TARGET "step-49")
# Declare all source files the target consists of:
SET(TARGET_SRC
${TARGET}.cc
# You can specify additional files here!
)
# Usually, you will not need to modify anything beyond this point...
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
FIND_PACKAGE(deal.II 8.0 QUIET
HINTS ${deal.II_DIR} ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
)
IF(NOT ${deal.II_FOUND})
MESSAGE(FATAL_ERROR "\n"
"*** Could not locate deal.II. ***\n\n"
"You may want to either pass a flag -DDEAL_II_DIR=/path/to/deal.II to
cmake\n"
"or set an environment variable \"DEAL_II_DIR\" that contains this path."
)
ENDIF()
DEAL_II_INITIALIZE_CACHED_VARIABLES()
PROJECT(${TARGET})
DEAL_II_INVOKE_AUTOPILOT()
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace dealii;
int main ()
{
Triangulation<2> triangulation;
GridIn<2> gridin;
gridin.attach_triangulation(triangulation);
std::ifstream f("mesh.inp");
gridin.read_abaqus(f);
GridOut gridout;
std::ofstream fout("mesh.vtu");
gridout.write_vtu(triangulation, fout);
}
mesh.inp
Description: Binary data
[deal.II] Can GridIn read 3D quad mesh?
Dear all, Sorry for the beginner question. I am trying to load a 3D quad mesh (i.e. not all nodes are co-planar for one element) to implement a Mindlin–Reissner plate. I wonder, can GridIn class read such meshes? Upon reading the document, it seems like if the input element is quad then it is a 2D mesh; but for shell elements the spatial information is 3D. Thank you! Shawn -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Help needed - remote debug in VS2017 hangs when MPI_InitFinalize is called
Hi Professor Bangerth, Thank you for the reply! And sorry for the late response. 1. Yes I can step into other lines of code fine :) 2. Hitting Ctrl-C twice does not do anything and it still hangs there. However, good news - we tracked it down on GitHub! The initial discussion started here: https://github.com/dealii/dealii/issues/6919#issuecomment-405028538 And then went here: https://github.com/Microsoft/WSL/issues/3428 And it should be resolved for now. I'm still waiting for our IT department to upgrade my Windows to be able to see it, so I'll report back when I try it! Thanks to everyone who helped! Shawn On Friday, July 13, 2018 at 4:59:56 PM UTC-7, Wolfgang Bangerth wrote: > > On 07/12/2018 04:36 PM, Yuxiang Wang wrote: > > > > I tried and I can neither step over (n) nor step into (s) that line of > code - > > either way, it hangs right there. > > Can you step into other function calls? That's sort of the point of a > debugger, that you can get into functions :-) > > When it hangs, hit Ctrl-C (maybe twice, if necessary). This should stop > execution at the place where it hangs. You can then type 'backtrace' to > get a > listing of where execution currently is. > > > > As for I run with just one processor - sorry but I am not sure about the > > question. The workstation is dual processor with 8 cores each; the > program was > > unchanged from the documentation. Or were you inquiring about something > else? > > The number of processors doesn't matter. If you just say >./step-xy > then it's going to use just one MPI process. (Though each MPI process may > use > multiple cores for shared memory parallelization, but that's a separate > matter.) > > If you want to use multiple MPI processes, you need to run the code as in >mpirun -np 8 ./step-xy > for example. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Interior node locations for higher order elements
Hi Bruno, Exactly what I was looking for. Thank you so much! Best, Shawn On Fri, Apr 20, 2018 at 1:29 PM, Bruno Turcksin <bruno.turck...@gmail.com> wrote: > Shawn, > > On Friday, April 20, 2018 at 2:31:28 PM UTC-4, Yuxiang Wang wrote: >> >> Could you please help point to me where this is documented, about the >> rule of where higher order interior nodes are located? >> > See here http://dealii.org/8.5.0/doxygen/deal.II/classFE__Q.html and here > is the relevant part: > > Implementation of a scalar Lagrange finite element Qp that yields the > finite element space of continuous, piecewise polynomials of degree p in > each coordinate direction. This class is realized using tensor product > polynomials based on 1D Lagrange polynomials with equidistant (degree up to > 2), Gauss-Lobatto (starting from degree 3), or given support points. > > The standard constructor of this class takes the degree p of this finite > element. Alternatively, it can take a quadrature formula points defining > the support points of the Lagrange interpolation in one coordinate > direction. > > Best, > > Bruno > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see https://groups.google.com/d/ > forum/dealii?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "deal.II User Group" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/dealii/7Ne9oVd75eo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > dealii+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Interior node locations for higher order elements
Hello dear deal.II community, Previously, I thought that for a high order element in 1D (cubic, for example), the interior nodes would be equally distributed at: Node 0 - 0 Node 1 - 0.01 Node 2 - 0.0033 Node 3 - 0.0067 However, in deal.II I found them to be at: Node 0 - 0 Node 1 - 0.01 Node 2 - 0.00276393 Node 3 - 0.00723607 Could you please help point to me where this is documented, about the rule of where higher order interior nodes are located? Thank you, Shawn -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Question wrt step-3: shape functions and test functions
Thank you Professor Bangerth for the answer! I appreciate your link to the video a lot. And thank you for the kind words - I'll try to work harder to match your expectations and one day contribute to deal.II :) Have a great one, Shawn On Monday, April 2, 2018 at 1:22:42 PM UTC-7, Wolfgang Bangerth wrote: > > > > In the step-3 example > > (https://www.dealii.org/8.4.1/doxygen/deal.II/step_3.html), I noticed > > that at first the variable phi is used as a test function. It is in the > > same space with u, except for that the value is 0 on the boundaries. (in > > this problem the boundary values for u is also 0, but it could be > > non-zero for general cases) > > > > However, later, the variable phi is also the shape function. I am lost > > in this step in understanding why the test function could be the shape > > function at the same time. For example, if the boundary conditions of u > > is non-zero, we'd have to have a shape function to be non-zero at the > > boundary (right?) but the test function space needs to be 0 on the > boundary. > > Your question shows a much deeper mathematical understanding of how > strong boundary conditions actually work than most of us actually have :-) > > While you are correct that one can solve the problem as you suggest, > deal.II tries to separate the treatment of boundary conditions from the > treatment of assembly. We like to do things in such a way that we can do > the exact same thing on each cell during assembly, without having to > wonder whether some of the degrees of freedom are at the boundary. We > then only later modify the resulting linear system so that it reflects > the boundary conditions. You may want to watch lectures 21.6 and 21.65 > here >http://www.math.colostate.edu/~bangerth/videos.html > where I discuss exactly these sorts of issues and how they are done > algorithmically. > > Best > W. > > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Question wrt step-3: shape functions and test functions
Dear all, Sorry for the spam - a basic mathematical question. In the step-3 example (https://www.dealii.org/8.4.1/doxygen/deal.II/step_3.html), I noticed that at first the variable phi is used as a test function. It is in the same space with u, except for that the value is 0 on the boundaries. (in this problem the boundary values for u is also 0, but it could be non-zero for general cases) However, later, the variable phi is also the shape function. I am lost in this step in understanding why the test function could be the shape function at the same time. For example, if the boundary conditions of u is non-zero, we'd have to have a shape function to be non-zero at the boundary (right?) but the test function space needs to be 0 on the boundary. Could you please help? Thank you, Shawn -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Are shell elements available in deal.II?
Thank you again Professor Bangerth and mac! As you can understand, implementing a Mindlin-Reissner element along with appropriate shear-locking relieves (MITC7/MITC9) indeed seems daunting at a first glance (at least for me). I was hoping that I can get some example code for a head start, but since those are not available, I'll just jump in and try my best to implement one. If I would be able to make it, I'd be happy to share my code! Best, Shawn On Monday, March 26, 2018 at 6:59:33 AM UTC-7, mac wrote: > > Hi > > I’ve hesitated to add this link as it predates many of the features in > deal.II that would have made the implementation a lot more elegant and > simple. Nevertheless have a look at > https://open.uct.ac.za/handle/11427/5552 It’s a fully nonlinear shell > theory due to Simo & Fox implemented in deal.II. > > There is no reason why you can’t implement Mindlin-Reissner plate theory > in deal.II. I would start with Timoshenko beam theory and then build up to > plates. > > A > > > > On 26 Mar 2018, at 14:40, Wolfgang Bangerth <bang...@colostate.edu > > wrote: > > On 03/25/2018 11:44 AM, Yuxiang Wang wrote: > > My current need for shell element is for solid mechanics problem > (Mindlin-Reissner plates). A simple example could be that a thick square > plate, with all its edges fixed, under a force loading at the center. The > dimensions of the plate are around 10x of its thickness; so, as one can > note, there is 1) only in-plate stress in this problem, 2) the plate > thickness remains constant during the deformation, and 3) there is an > approximately linear variation of displacement across the thickness > direction. > Do you happen to be aware of any examples in deal.ii, that solves shell > problems for solid mechanics application? If not, I can also try to start > from scratch; but I figured it'd be nice that if I know someone who did > this already and wouldn't need to reinvent the wheels. > > > I don't know of any that would be publicly available. I know that Baerbel > Janssen's diploma thesis was on biharmonic problems (or at least had them > as part). You can get it from here but it is in German: > http://www.csc.kth.se/~barbel/link/en/publications.shtml > > I am certain that others have done similar work, but I don't know the > details. Of course, we are always grateful to anyone willing to share their > codes through the code gallery! > > Best > Wolfgang > > -- > > Wolfgang Bangerth email: ...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- You received this message because you are subscribed to the Google > Groups "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dealii+un...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Are shell elements available in deal.II?
Hi Professor Bangerth, Thank you for the pointer! Those are very helpful. I just realized that Mindlin-Reissner plate theory can be expressed in forms of mixed elements. My current need for shell element is for solid mechanics problem (Mindlin-Reissner plates). A simple example could be that a thick square plate, with all its edges fixed, under a force loading at the center. The dimensions of the plate are around 10x of its thickness; so, as one can note, there is 1) only in-plate stress in this problem, 2) the plate thickness remains constant during the deformation, and 3) there is an approximately linear variation of displacement across the thickness direction. Do you happen to be aware of any examples in deal.ii, that solves shell problems for solid mechanics application? If not, I can also try to start from scratch; but I figured it'd be nice that if I know someone who did this already and wouldn't need to reinvent the wheels. Thank you! Shawn On Tuesday, March 6, 2018 at 3:50:53 PM UTC-8, Wolfgang Bangerth wrote: > > > > I am excited to learn that there are arguably better methods (mixed > methods) > > to solve shell problems. I am not familiar with those; could you please > kindly > > provide some pointers for me to start (anything, either example, code, > or paper)? > > That all depends on what equation exactly you're looking at solving. For > the > biharmonic equation, you could for example start looking here: > > > https://scholar.google.co.jp/scholar?hl=en_sdt=0%2C5=mixed+methods+biharmonic+equation= > > > https://scholar.google.co.jp/scholar?hl=en_sdt=0%2C5=discontinuous+galerkin+biharmonic+equation= > > > Beyond that, you'd have to be more specific about what you want to do. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Re: For docker, cmake runs examples fine when I run it in the pre-installed src example folder, but not after I copied it to ~/shared
I realized that my previous post is a bit confusing as I did not break the error message into small sections. Here is the update: At first I did forget to remove the `CMakeCache.txt`: ``` dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cp -r ~/dealii-v8.5.1-src/examples ~/shared/examples dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cd ~/shared/examples/step-1 dealii@d0e24c0315a5:~/shared/examples/step-1$ cmake CMakeLists.txt CMake Error: The current CMakeCache.txt directory /home/dealii/shared/examples/step-1/CMakeCache.txt is different than the directory /home/dealii/dealii-v8.5.1-src/examples/step-1 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt CMake Error: The source "/home/dealii/shared/examples/step-1/CMakeLists.txt" does not match the source "/home/dealii/dealii-v8.5.1-src/examples/step-1/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. ``` So I removed all those files except for the `step-1.cc` and the `CMakeLists.txt`: ``` dealii@d0e24c0315a5:~/shared/examples/step-1$ ls | grep -v 'CMakeLists.txt\|step-1.cc' | xargs rm -rf dealii@d0e24c0315a5:~/shared/examples/step-1$ ls CMakeLists.txt step-1.cc ``` And then I re-ran the `cmake` command, and encountered an issue where `mpicc` is not working: ``` dealii@d0e24c0315a5:~/shared/examples/step-1$ cmake CMakeLists.txt -- The C compiler identification is GNU 6.2.0 -- The CXX compiler identification is GNU 6.2.0 -- Check for working C compiler: /usr/bin/mpicc -- Check for working C compiler: /usr/bin/mpicc -- broken CMake Error at /usr/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/usr/bin/mpicc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/dealii/shared/examples/step-1/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_f6b04/fast" make: *** No rule to make target 'cmTC_f6b04/fast'. Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:38 (PROJECT) -- Configuring incomplete, errors occurred! See also "/home/dealii/shared/examples/step-1/CMakeFiles/CMakeOutput.log". See also "/home/dealii/shared/examples/step-1/CMakeFiles/CMakeError.log". ``` On Thursday, March 22, 2018 at 11:58:34 AM UTC-7, Yuxiang Wang wrote: > > Short summary: cmake runs examples fine when I run it in the pre-installed > src example folder, but not after I copied it to ~/shared. Could you please > help see why? > > Full story: first, when I run it in the pre-installed src example folder, > it works: > ``` > E:\dealii>docker pull > dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease > v8.5.1-gcc-mpi-fulldepscandi-debugrelease: Pulling from dealii/dealii > Digest: > sha256:5c6ed25801292f715136bdad411e7dcda1d8f647f60c31be10533aa2697582ac > Status: Image is up to date for > dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease > > E:\dealii>docker run -i -t -v E:\dealii:/home/dealii/shared > dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease > dealii@d0e24c0315a5:~$ cd dealii-v8.5.1-src/examples/step-1 > dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cmake > CMakeLists.txt > -- The C compiler identification is GNU 6.2.0 > -- The CXX compiler identification is GNU 6.2.0 > -- Check for working C compiler: /usr/bin/mpicc > -- Check for working C compiler: /usr/bin/mpicc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/mpicxx > -- Check for working CXX compiler: /usr/bin/mpicxx -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Autopilot invoked > ### > # > # Project step-1 set up with deal.II-8.5.1 found at > # /home/dealii/dealii-v8.5.1 > # > # CMAKE_BUILD_TYPE: Debug > # > # You can now run > # $ make- to compile and link the program > # $ make run- to (compile, link and) run the program > # > # $ make debug - to switch the build type to 'Debug' > # $ make release- to switch the build type to 'Release' > # > # $ make edit_cache - to change (cached) configuration variables > # and rerun the configure and generate > phases of CMake > # > # $ make strip_comments - to strip the source files in this > # directory off
[deal.II] For docker, cmake runs examples fine when I run it in the pre-installed src example folder, but not after I copied it to ~/shared
Short summary: cmake runs examples fine when I run it in the pre-installed src example folder, but not after I copied it to ~/shared. Could you please help see why? Full story: first, when I run it in the pre-installed src example folder, it works: ``` E:\dealii>docker pull dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease v8.5.1-gcc-mpi-fulldepscandi-debugrelease: Pulling from dealii/dealii Digest: sha256:5c6ed25801292f715136bdad411e7dcda1d8f647f60c31be10533aa2697582ac Status: Image is up to date for dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease E:\dealii>docker run -i -t -v E:\dealii:/home/dealii/shared dealii/dealii:v8.5.1-gcc-mpi-fulldepscandi-debugrelease dealii@d0e24c0315a5:~$ cd dealii-v8.5.1-src/examples/step-1 dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cmake CMakeLists.txt -- The C compiler identification is GNU 6.2.0 -- The CXX compiler identification is GNU 6.2.0 -- Check for working C compiler: /usr/bin/mpicc -- Check for working C compiler: /usr/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/mpicxx -- Check for working CXX compiler: /usr/bin/mpicxx -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Autopilot invoked ### # # Project step-1 set up with deal.II-8.5.1 found at # /home/dealii/dealii-v8.5.1 # # CMAKE_BUILD_TYPE: Debug # # You can now run # $ make- to compile and link the program # $ make run- to (compile, link and) run the program # # $ make debug - to switch the build type to 'Debug' # $ make release- to switch the build type to 'Release' # # $ make edit_cache - to change (cached) configuration variables # and rerun the configure and generate phases of CMake # # $ make strip_comments - to strip the source files in this # directory off the documentation comments # $ make clean - to remove the generated executable as well as # all intermediate compilation files # $ make runclean - to remove all output generated by the program # $ make distclean - to clean the directory from _all_ generated # files (includes clean, runclean and the removal # of the generated build system) # $ make info - to view this message again # # Have a nice day! # ### -- Configuring done -- Generating done -- Build files have been written to: /home/dealii/dealii-v8.5.1-src/examples/step-1 dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ make run Scanning dependencies of target step-1 [ 33%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o [ 66%] Linking CXX executable step-1 [ 66%] Built target step-1 Scanning dependencies of target run [100%] Run step-1 with Debug configuration Grid written to grid-1.eps Grid written to grid-2.eps [100%] Built target run ``` However, if I copy the examples to my local folder, it wouldn't work. (Sorry for the 2 lines where I forgot to delete the files first) ``` dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cp -r ~/dealii-v8.5.1-src/examples ~/shared/examples dealii@d0e24c0315a5:~/dealii-v8.5.1-src/examples/step-1$ cd ~/shared/examples/step-1 dealii@d0e24c0315a5:~/shared/examples/step-1$ cmake CMakeLists.txt CMake Error: The current CMakeCache.txt directory /home/dealii/shared/examples/step-1/CMakeCache.txt is different than the directory /home/dealii/dealii-v8.5.1-src/examples/step-1 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt CMake Error: The source "/home/dealii/shared/examples/step-1/CMakeLists.txt" does not match the source "/home/dealii/dealii-v8.5.1-src/examples/step-1/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory. dealii@d0e24c0315a5:~/shared/examples/step-1$ ls | grep -v 'CMakeLists.txt\|step-1.cc' | xargs rm -rf dealii@d0e24c0315a5:~/shared/examples/step-1$ ls CMakeLists.txt step-1.cc dealii@d0e24c0315a5:~/shared/examples/step-1$ cmake CMakeLists.txt -- The C compiler identification is GNU 6.2.0 -- The CXX compiler identification is GNU 6.2.0 -- Check for working C compiler: /usr/bin/mpicc -- Check for working C compiler: /usr/bin/mpicc -- broken CMake Error at /usr/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/usr/bin/mpicc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/dealii/shared/examples/step-1/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_f6b04/fast"
Re: [deal.II] Are shell elements available in deal.II?
Thank you Professor Bangerth for your response! Yes that's exactly what I am interested in. I am excited to learn that there are arguably better methods (mixed methods) to solve shell problems. I am not familiar with those; could you please kindly provide some pointers for me to start (anything, either example, code, or paper)? Best, Shawn On Tuesday, March 6, 2018 at 1:13:24 AM UTC-8, Wolfgang Bangerth wrote: > > > Shawn, > > > I tried to search but did not find an implementation of shell elements > in > > deal.II. Since this is a commonly used element, I'd like to make sure > that > > it's not me missing it. Could you please help confirm? > > That depends on how exactly you define "shell elements". But if you mean > "elements that are not only continuous but also have continuous > derivatives, > for use in problems with fourth derivatives", then the answer is "no". > > Of course, there are other approaches to solve shell problems -- maybe > even > better ones than using shell elements -- that are available in deal.II. > This > includes using mixed methods. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Are shell elements available in deal.II?
Hi, Sorry for the spam. I tried to search but did not find an implementation of shell elements in deal.II. Since this is a commonly used element, I'd like to make sure that it's not me missing it. Could you please help confirm? Best, Shawn -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
