[deal.II] Re: Untraceable "not implemented" error in GDB
Yep that does it! Thanks for your patience :) On Friday, September 16, 2016 at 7:28:41 PM UTC+2, Bruno Turcksin wrote: > > Alex, > > before the run command, you need to use: catch throw > > Best, > > Bruno > > On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote: >> >> A couple of times now I have encountered GDB output similar to my >> attached snapshot. >> >> The previous time I had only made a very small change to my code, so it >> was easy enough for me to figure out on my own. Presently I'm trying to run >> a 1D version of my code for the first time. So far I've only ran 2D >> problems, though I have been attempting to employ the dimension independent >> programming found throughout the library. >> >> So I imagine that there is some templated method I'm using which simply >> has not been implemented in 1D. Any tips on how to quickly narrow down >> which specific method(s) is/are throwing this exception? Is it extremely >> odd that this exception doesn't point me to the source code? >> >> I'm on Ubuntu 14.04 and using a debug build of a 8.5.0-pre version of >> deal.II at commit 0752c81b84c7f9c737ef62ac09932853bb976f8d >> >> As shown in the snapshot, GDB has consistently been throwing a couple of >> warnings. I always get those warnings and this is only the second time I've >> had an untraceable error, both of which are related to the "not >> implemented" cases; so I'm guessing that it's unrelated, but I could be >> entirely wrong about that. >> >> Any ideas? Thanks! >> > -- 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] Help with Vector template instantiations
True, I've checked in the master and it is templated for the Function too. I use 8.4.1. It's fine then. Thanks. On Friday, September 16, 2016 at 5:39:33 PM UTC+1, Wolfgang Bangerth wrote: > > On 09/15/2016 05:12 AM, dragn...@gmail.com wrote: > > > > One more question, in fact a small inconsistency that is of my interest: > > the function VectorTools::interpolate_boundary_values is not templated > > for the generic Number type but for double only (argument > > std::map& boundary_values). Is there a > > reason for that? > > Which version of deal.II are you using? In the current development > version, this is properly templated so that the value type of the > Function object is the same as the value type of the boundary_values map. > > Best > Wolfgang > > -- > > 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: Untraceable "not implemented" error in GDB
Alex, before the run command, you need to use: catch throw Best, Bruno On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote: > > A couple of times now I have encountered GDB output similar to my attached > snapshot. > > The previous time I had only made a very small change to my code, so it > was easy enough for me to figure out on my own. Presently I'm trying to run > a 1D version of my code for the first time. So far I've only ran 2D > problems, though I have been attempting to employ the dimension independent > programming found throughout the library. > > So I imagine that there is some templated method I'm using which simply > has not been implemented in 1D. Any tips on how to quickly narrow down > which specific method(s) is/are throwing this exception? Is it extremely > odd that this exception doesn't point me to the source code? > > I'm on Ubuntu 14.04 and using a debug build of a 8.5.0-pre version of > deal.II at commit 0752c81b84c7f9c737ef62ac09932853bb976f8d > > As shown in the snapshot, GDB has consistently been throwing a couple of > warnings. I always get those warnings and this is only the second time I've > had an untraceable error, both of which are related to the "not > implemented" cases; so I'm guessing that it's unrelated, but I could be > entirely wrong about that. > > Any ideas? Thanks! > -- 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] Untraceable "not implemented" error in GDB
A couple of times now I have encountered GDB output similar to my attached snapshot. The previous time I had only made a very small change to my code, so it was easy enough for me to figure out on my own. Presently I'm trying to run a 1D version of my code for the first time. So far I've only ran 2D problems, though I have been attempting to employ the dimension independent programming found throughout the library. So I imagine that there is some templated method I'm using which simply has not been implemented in 1D. Any tips on how to quickly narrow down which specific method(s) is/are throwing this exception? Is it extremely odd that this exception doesn't point me to the source code? I'm on Ubuntu 14.04 and using a debug build of a 8.5.0-pre version of deal.II at commit 0752c81b84c7f9c737ef62ac09932853bb976f8d As shown in the snapshot, GDB has consistently been throwing a couple of warnings. I always get those warnings and this is only the second time I've had an untraceable error, both of which are related to the "not implemented" cases; so I'm guessing that it's unrelated, but I could be entirely wrong about that. Any ideas? Thanks! -- 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] Help with Vector template instantiations
On 09/15/2016 05:12 AM, dragniko...@gmail.com wrote: One more question, in fact a small inconsistency that is of my interest: the function VectorTools::interpolate_boundary_values is not templated for the generic Number type but for double only (argument std::map& boundary_values). Is there a reason for that? Which version of deal.II are you using? In the current development version, this is properly templated so that the value type of the Function object is the same as the value type of the boundary_values map. Best Wolfgang -- 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 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: Failing to set up simple test configuration
Timo, when I looked into this before posting my question, it seemed to be a pretty clear issue with the perl command not working on the Windows filesystem. Per my recent reply to Wolfgang, I have moved forward with a simple work-around (which simply does not involve running ctest on the Windows file system). I imagine at some point in the not-so-distant future I'll be interested in fixing this. Of course please do let me know if you're interested and want to to reproduce the log for the group's purposes. Thanks. On Wednesday, September 7, 2016 at 6:44:09 PM UTC+2, Timo Heister wrote: > > Hey Alex, > > I am not surprised you are running into issues, because you are the > first one to try "ubuntu on windows" to compile deal.II with (at least > as far as I know). > > It could be a permission problem that you are running into, who knows. > Would you mind sharing you deal.II detailed.log? > > On Wed, Sep 7, 2016 at 9:32 AM, Jean-Paul Pelteret > wrote: > > Hi Alex, > > > > Great, many thanks for your useful feedback. I've alerted the other > > developers to your comments so that they can be considered in the > discussion > > about getting deal.II to properly on windows. > > > > Cheers, > > J-P > > > > > > On Wednesday, September 7, 2016 at 2:56:10 PM UTC+2, Alex Zimmerman > wrote: > >> > >> The recent Windows 10 "Anniversary Update" included an entire built-in > >> Ubuntu (14.04) subsystem: > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en-2Dus_commandline_wsl_about&d=CwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=WDpmF-SkGP5uKyQ0vKXcggIG-I_RfG1fLlDteZEDQ_s&s=iVn3ecqjKuFP2DxDo7Q8ippSqeZvU8HaFT57rzJEvRQ&e= > > >> > >> I've built a few different versions of deal.II on this system, > including > >> the candi build with Trilinos, p4est, etc. This was all painless, so > >> definitely try it out if you can use the latest version of Windows. > >> > >> It's actually called "Bash on Ubuntu on Windows", and it's marketed as > >> just being a bash prompt useful for command line tools; but it appears > much > >> more capable than that. Also it can read/write from/to the entire > Windows C: > >> drive, which is the "/mnt/c" path in my question. This has been useful > so > >> that I can use Notepad++ and Paraview from Windows. "Bash on Ubuntu on > >> Windows" currently isn't very good at forwarding graphics. Even gedit > >> doesn't forward very well. There might be some low level magic that > >> Microsoft has performed to make all of this work. Presently it appears > that > >> my issue is related to MS-DOS not allowing my ctest to do some inline > file > >> editing on my C: drive. But this is indeed to first issue I've had, so > the > >> system looks quite promising. > >> > >> After some brief Googling, I think I might even be able to fix this > issue > >> if I could find where the code is that is causing the error "Can't do > >> inplace edit on > >> > /mnt/c/Users/Alexander/UbuntuShared/dimice-heat-dealii/build/tests/cylinder.debug/output: > > > >> No such file or directory." Unfortunately I'm completely unfamiliar > with the > >> test system and I have not a clue. > >> > >> > >> On Wednesday, September 7, 2016 at 10:29:54 AM UTC+2, Jean-Paul > Pelteret > >> wrote: > >>> > >>> Great, glad that you sorted it out! > >>> > >>> By the way, there's recently been a discussion on GitHub related to > >>> running deal.II on windows. Its interesting to hear that you've got it > >>> running on Windows 10. Out of curiosity, how have you configured > deal.II? Do > >>> you link it against any external libraries? > >>> > >>> On Wednesday, September 7, 2016 at 10:07:06 AM UTC+2, Alex Zimmerman > >>> wrote: > > This might be a problem with my file system. I've been successfully > using the Ubuntu subsystem on Windows 10 for the past few weeks, and > that's > where the odd "/mnt/c/Users..." path comes from in my question. > > I just tried this again at my home directory, and it worked. I > thought I > had tried running the test on my user project in my home directory, > but I'm > fairly sure I never tried this simple step-1 example there. > > So now this is working: > > $ ctest > > > > > > Test project /home/zimmerman/temp/step-1/build > > Start 1: tests/my_test.debug > > 1/1 Test #1: tests/my_test.debug .. Passed5.51 sec > > 100% tests passed, 0 tests failed out of 1 > > Total Test time (real) = 5.52 sec > > > > One of these days I'll ask a question that I don't answer myself a > few > minutes later :) > > > On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex Zimmerman > wrote: > > > > Maybe this is a bug, but I think it's more likely that I'm doing > > somethin
Re: [deal.II] Re: Failing to set up simple test configuration
Wolfgang, thanks for pointing me to this part of the code. I'm not sure
when I'll try to fix the problem, because it was very simple to just only
ever run ctest on the Linux filesystem, completely circumventing it. I'll
make sure to post an update if I ever fix this so that I can run ctest on
the Windows filesystem (from the bash prompt).
On Wednesday, September 7, 2016 at 10:36:21 PM UTC+2, Wolfgang Bangerth
wrote:
>
> On 09/07/2016 06:56 AM, Alex Zimmerman wrote:
> >
> > After some brief Googling, I think I might even be able to fix this
> issue if I
> > could find where the code is that is causing the error "Can't do inplace
> edit
> > on
> >
> /mnt/c/Users/Alexander/UbuntuShared/dimice-heat-dealii/build/tests/cylinder.debug/output:
>
>
> > No such file or directory." Unfortunately I'm completely unfamiliar with
> the
> > test system and I have not a clue.
>
> This happens in cmake/macros/macro_deal_ii_add_test.cmake, around line
> 240:
>
>ADD_CUSTOM_COMMAND(OUTPUT ${_test_directory}/output
> COMMAND sh
> ${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/run_test.sh
>run "${_test_full}" "${_run_command}" "${_test_diff}"
>"${DIFF_EXECUTABLE}" "${_comparison_file}"
> COMMAND ${PERL_EXECUTABLE}
>-pi ${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/
> normalize.pl
>${_test_directory}/output
> WORKING_DIRECTORY
>${_test_directory}
> DEPENDS
>${_target}
>${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/normalize.pl
> VERBATIM
> )
>
> We here call "perl -pi ".
>
> 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: 1D version of step3
Bruno, Yeah, I noticed an old discussion with the same problem and solved it. Thanks, Weixiong 在 2016年9月16日星期五 UTC-5上午10:42:30，Bruno Turcksin写道： > > Weixong, > > On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote: >> >> When running the program, the solution is zero on the left side as >> expected. However, the right side solution is something nonzero. Since I am >> using the same apply_boundary_condition settings, I am supposed to get zero >> solution on both boundaries, right? >> > I don't think so. I think that in 1D, the left side has always a > boundary_id of 0 and the right side has a boundary_id of 1. > > 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 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: 1D version of step3
Weixong, On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote: > > When running the program, the solution is zero on the left side as > expected. However, the right side solution is something nonzero. Since I am > using the same apply_boundary_condition settings, I am supposed to get zero > solution on both boundaries, right? > I don't think so. I think that in 1D, the left side has always a boundary_id of 0 and the right side has a boundary_id of 1. 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 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] 1D version of step3
Dear all, I just tried to modify step-3 to 1D. The changes are minor. The equation is changed to be with a small reaction. The mesh is generated with subdivided_hyper_cube (triangulation, 50, 0, 10); I changed all the <2>, the dimension, to <1>. When running the program, the solution is zero on the left side as expected. However, the right side solution is something nonzero. Since I am using the same apply_boundary_condition settings, I am supposed to get zero solution on both boundaries, right? Am I missing something? Thanks in advance. Weixiong -- 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] Parasitic stress in corners with periodic boundary conditions
Hi, sorry for this late reply. I missed it and realized just now. I found the problem, which is simply that if the whole system is fully periodic ( I mean, for example from plane to torus topology) then the 4 corners become effectively fixed (the other possibility would be rigid body motion). The fact that this 4 nodes become fixed, makes that when some eigenstrain is prescribed somewhere, unexpected stress appears close to the corners as the system can't fully relax there. I think this is something one was to live with. I didn't see it with other FEM packages because the solution suffered some post processing before I got it, which smoothed the result and somehow hide this. On Monday, 2 June 2014 00:59:11 UTC+2, Wolfgang Bangerth wrote: > > On 05/28/2014 10:29 AM, David F wrote: > > Hello, my problem is the following: > > > > I prescribe an eigenstrain value in one element of the grid (i.e., an > inner > > element undergoes a certain transformation and this introduces strain > and > > stress in the rest of the grid), and everything works fine for normal > > boundaries and periodic boundaries. However, if one pays close > attention, for > > the periodic boundary solution in the corners of the grid one can see > some > > parasitic stress that shouldn't be there. > > > > I think the reason is the following: prescribing, let's say, a shear > > eigenstrain in one element, the four corners (in 2D) of the grid deform > in > > opositte directions if the boundary is not periodic, therefore when it > is > > periodic the four corners are in fact "the same", and these 4 opposite > > displacements would add up to 0, effectively fixing the "corner node". > This > > seems to me a natural problem of FEM and periodicity, so I have no clue > how to > > correct this with code. > > > > I have used other FEM packages for solving exactly the same problem I > > described, and somehow this is not happening, so there must be a way to > avoid > > this. I am not sure if it has to do with my implementation of the > periodic > > boundaries, or maybe the way in which deal.ii deals with periodicity is > the > > reason, or maybe I have to apply some kind of postprocessing correction > of > > which I am not aware yet. > > > > Does anyone know why could this be? > > I don't know myself. Maybe someone else does. But I'd like to point out > that > using periodic boundary conditions is equivalent to looking at a problem > where > you have periodic array of sources. Is the element where you prescribe the > eigenstrain by chance close to a corner of your domain? If so, I would > expect > there to be some strain close to the opposite corner as well, simply > because > there is a source (outside your domain) close to that opposite corner. > > It may be worthwhile sending a picture that shows what you are observing. > > > > P.S.: my periodic boundary implementation is a direct extension of > step-45 and > > everything but these small parasitic stress in the corners is pretty > accurate, > > so probably a problem in the code is not reason. Should I try with > > DoFTools::make_periodicity_constraints or do you the problem will be > exactly > > the same? > > Hard to tell. It's probably worth a try. > > Best > W. > -- > > Wolfgang Bangerth email:bang...@math.tamu.edu > > www: http://www.math.tamu.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: CXX flags for SIMD and other optimization flags (GCC@6)
A useful flag that I use in release mode is -funsafe-loop-optimizations, which assumes that loop counters cannot overflow and other such things. I don't remember the exact numbers but I do remember that using this flag made a small, but measurable, performance improvement. On Thursday, September 15, 2016 at 8:04:58 AM UTC-4, Denis Davydov wrote: > > Dear all, > > From the matrix-free tutorials 37 and 48, I see that the recommended flags > for VectorizedArrays with GCC are > > -DCMAKE_CXX_FLAGS="-march=native" > > How about using -O3, -ffast-math, -funroll-loops ? Any other recommended > flags for GCC? > > Regards, > 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] Re: Help with time stepping methods
I have created a pull request here: https://github.com/dealii/dealii/pull/3123 Thanks again Bruno 2016-09-16 10:01 GMT-04:00 Bruno Turcksin : > 2016-09-16 9:22 GMT-04:00 Vaibhav Palkar : >> >> The error being exactly zero is indeed intriguing. I'm still looking out for >> the reason why that is happening. I didn't understand what you meant by a >> "ramp in time". Could you please elaborate? > Since you are using a low order method in time, I am just wondering if > the solution is linear in time. This is one way to have the exact > solution at each time step and it could explain why the error is zero > (assuming that there is no spatial error) > >> Step-52 works fine, I'm getting exactly the same results as the online >> documentation. I looked at time_stepping.templates.h, I think there is a bug >> around line 730, delta_t_guess should be assigned the value of new_delta_t >> (the coarsened time step) rather than delta_t (old time step). > Good catch!! Patch incoming. > > Thanks > > 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 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 with time stepping methods
2016-09-16 9:22 GMT-04:00 Vaibhav Palkar : > > The error being exactly zero is indeed intriguing. I'm still looking out for > the reason why that is happening. I didn't understand what you meant by a > "ramp in time". Could you please elaborate? Since you are using a low order method in time, I am just wondering if the solution is linear in time. This is one way to have the exact solution at each time step and it could explain why the error is zero (assuming that there is no spatial error) > Step-52 works fine, I'm getting exactly the same results as the online > documentation. I looked at time_stepping.templates.h, I think there is a bug > around line 730, delta_t_guess should be assigned the value of new_delta_t > (the coarsened time step) rather than delta_t (old time step). Good catch!! Patch incoming. Thanks 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 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 with time stepping methods
On Friday, September 16, 2016 at 1:38:57 AM UTC+5:30, Bruno Turcksin wrote: > I don't see anything wrong. The output says that your error is zero, > are you doing a simple ramp in time? It's very strange that the error > is exactly zero. What happens if you just use the default parameters? > Does step-52 work correctly? The delta_t_guess is computed around line > 715 in include/dealii/base/time_stepping.templates.h You could put a > couple of cout there to see what's happening (you will need to > recompile deal though) > The error being exactly zero is indeed intriguing. I'm still looking out for the reason why that is happening. I didn't understand what you meant by a "ramp in time". Could you please elaborate? Step-52 works fine, I'm getting exactly the same results as the online documentation. I looked at time_stepping.templates.h, I think there is a bug around line 730, delta_t_guess should be assigned the value of new_delta_t (the coarsened time step) rather than delta_t (old time step). Thanks, Vaibhav -- 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: How to find all the partial derivatives of the solution polynomial in deal.II
Jiaqi, Currently you can access first, second and third partial derivatives in FEValues. The FiniteElement class also implements fourth derivatives. If this is sufficient for your purposes, then using FEValues*::third_derivative should be fine for you. I don't see a easier way at the moment. 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.
