That's interesting. Seems like it was more about inlining than branch
prediction. Surprising how much difference it made.
On Tuesday, January 5, 2021 at 6:18:38 PM UTC-5 Timo Heister wrote:
> What I forgot to say:
> We used to have something like
>
> if (use_anisotropic_viscosity==true)
>
implement with very little refactoring.
Lastly, this might not be as helpful, but C++20 has the "un/likely"
attribute that can give hints the compiler to favour a branch.
Best regards,
Doug
On Tuesday, January 5, 2021 at 4:48:00 PM UTC-5 blais...@gmail.com wrote:
> Hi Timo,
>
>
Thanks for the clarification! I initially thought ghost neighbours would
only include face neighbours. That solves the problem.
On Thu, Oct 22, 2020, 09:33 Wolfgang Bangerth
wrote:
> On 10/21/20 7:46 PM, Doug Shi-Dong wrote:
> > Thanks, yes, that should work well for 2D. I actu
to
the corner cells will have a vertex on the boundary, but none of its
neigbor actually lie on the boundary.
Any advice on how to approach this since the current processor would not
find it within its ghost cells?
Doug
On Wednesday, October 21, 2020 at 9:24:35 PM UTC-4 Wolfgang Bangerth wrote
that account for all the corners/edges DoFs that might be on a
boundary, but that seems inefficient.
Anyone knows of a better way within deal.II to deal with this?
Best regards,
Doug
On Friday, May 1, 2020 at 7:21:42 PM UTC-4 Wolfgang Bangerth wrote:
> On 5/1/20 5:07 PM, Shahab Golshan wrote:
> &g
tually implemented sacado_fad_fad first because I understood it
theoretically. Turns out, it was a bottleneck in my code, so I need
sacado_rad_fad. Might just switch the AD package.
Thanks again, following-up with a documentation PR
https://github.com/dealii/dealii/pull/10818
Doug
On Tuesday, Aug
let me know what you think. It's likely completely in the hand of
the Sacado group unless I start digging in their code. However, if it is
something that will likely not get fixed, we might want to put a warning on
the "Supported automatic differentiation libraries" page.
Bes
Yes I can confirm, I am using QProjector with a dummy face Quadrature right
now it works as intended.
Doug
--
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
Agreed. Sorry for the confusion. Looked back at my code and it's probably
the most straightforward way.
For some other unrelated reason I didn't want to use FEValues and directly
deal with the Mapping class.
Doug
On Monday, June 22, 2020 at 5:05:57 PM UTC-4, Simon Sticko wrote:
>
&
it to
transform_unit_to_real_cell().
Doug
On Sunday, June 21, 2020 at 8:10:30 PM UTC-4, Lex Lee wrote:
>
> Hello Doug,
>
> Thanks for your kind help.
>
> I am trying to understand your suggestion in the original email.
>
> Are you suggesting me u
lways know whether your point is on the face or not.
Therefore, transform_unit_to_real_cell() should do the trick. Unless you
somehow actually need to project a "volume" point, but projecting within
unit cell is easy, which you would then follow with
transform_unit_to_real_cell().
ode:
https://github.com/dougshidong/PHiLiP/tree/full_space_optimization/src/mesh)
I'd love to hear an update when you succeed
Doug
On Monday, June 8, 2020 at 12:22:08 PM UTC-4, Bruno Blais wrote:
>
> Dear all,
> I hope you are doing well.
>
> In my endless quest for robust mesh
More so, I just found that the AffineConstraints function have not been
instantiated for a mix of TrilinosWrappers::SparseMatrix and
LA::dist::Vector, hence it likely has not been tried out/tested.
Seems like it's just not a thing to use LA::dist::Vector other than for
matrix-free?
--
The
expecting too much from it? Maybe I just need to fix the LinearOperator
implementation to mix-and-match the data structure? If I do commit to
Trilinos matrices/vectors, will I have trouble doing some matrix-free or
GPU stuff in the far future?
Best regards,
Doug
--
The deal.II project is located
where it *doesn't* work well for me is actually in *serial
with hanging nodes*.
I'll report back here with the issue in the upcoming month or on Github
with an issue if I can pinpoint where it comes from.
Doug
On Tuesday, December 31, 2019 at 3:47:23 PM UTC-5, David Wells wrote:
>
> H
, the resulting Trilinos
vector was empty and would of course not have the same parallel
distribution as the matrix it was supposed to be multiplied with.
Doug
On Wednesday, December 4, 2019 at 6:25:49 PM UTC-5, Doug Shi-Dong wrote:
>
> Hello,
>
> I am trying to solve a block
with hanging nodes and Dirichlet boundary
condition. I was wondering what I should be careful about. In which
scenarios would those functions fail?
I couldn't find any issues on GitHub regarding those, or any mention of a
specific problem when git blaming.
Happy holidays!
Doug
--
The deal.II
to the Trilinos' Vector BlockMap in order to perform the
appropriate matrix-vector multiplication?
Another note: the matrix I'm looking to use is rectangular, and therefore
DomainMap() != RangeMap().
Best regards,
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum
Not sure why it builds fine locally, but that fixed it! Thank you!
Doug
On Wednesday, November 6, 2019 at 11:06:47 AM UTC-5, Wolfgang Bangerth
wrote:
>
> On 11/6/19 8:49 AM, Doug Shi-Dong wrote:
> >
> > Any hints about what could be causing this?
>
> I thou
in the current development version.
Are you aware of anyone hosting a "development" Docker build for their own
continuous integration. I know this can be very expensive to keep up with
the commits. Otherwise, I guess I should just build my own Docker with my
current deal.II fork.
Best rega
is ON, when my CMake
checks for it.
If no MPI is available, how do I compile the code within this Docker
container?
Best regards,
Doug
--
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
ents of order 4
or more.
Depending on where you want to take your code in the future, I'd be careful
with early code optimization like this. I would just stick with
communicating all the neighbor's dofs and optimize the code if you really
see a slowdown.
Doug
--
The deal.II project is l
062
if (cell->is_locally_owned())
to
if (cell->is_locally_owned() && cell->subdomain_id ==
subdomain_to_integrate)
Not sure if there is a more elegant way.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.co
eltai hinted at in the previous
post?
Best regards,
Doug
On Thursday, September 10, 2015 at 2:02:48 AM UTC-4, Praveen C wrote:
>
> Dear all
>
> I would like to use high order meshes for compressible flow computations
> around objects like airfoils. I would like to use Gmsh for th
On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth
wrote:
>
>
> Doug,
>
> It does not greatly surprise me that it doesn't compile -- what isn't
> tested
> generally doesn't work.
>
Makes sense.
We'd of course be very happy to accept any pat
ment that works for refine/distributed grids.
On Wednesday, September 18, 2019 at 12:33:43 AM UTC-4, vachan potluri wrote:
>
> Doug and Praveen,
>
> Thanks for your answers. I had a look at step-33. As far as I understand,
> although the looping through cells is not through MeshW
>
> so 'a' is of type Sacado::Fad::DFad. It then needs to call
>
>numbers::is_finite (Sacado::Fad::DFad), which doesn't exist.
> It probably just tries to go through all of the overloads of
> numbers::is_finite() and wants to see whether it can convert the
> argument Sacado::Fad::DFad to
es/dealii/include/deal.II/lac/la_parallel_vector.templates.h
itself calls AssertIsFinite. e.g. line 1450
In the end, it is basically trying to convert the Sacado type into a
complex number, which is undefined, whenever it tries to perform some
vector operations.
Doug
--
The deal.II project is loc
re I can control the metric degrees of freedom?
Doug
--
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
linear advection, your problems should be simple enough
that you wouldn't care about memory nor computational time. I haven't seen
people build those global matrices, but it should be faster than assembling
every loop. It's the old trade-off between memory and computation.
Doug
On Tuesday
On Monday, September 9, 2019 at 10:13:32 AM UTC-4, Wolfgang Bangerth wrote:
>
> 1.
>
> This seems like we are abusing the real_type for something it wasn't
> intended
> to do. Can you open a github issue with the error message you get with the
> unmodified code?
> 2.
>
> I suspect that
cally differentiate the entire Jacobian
and the sensitivities of the residual with respect to the grid points.
Best regards,
Doug
--
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
On Tuesday, August 27, 2019 at 3:51:20 AM UTC-4, Marc Fehling wrote:
>
>
> The patch has been merged. Let me know if this fix does the trick for you.
>
It does! Thank you again for the quick support.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailin
Thank you very much for the quick fix! Looking forward to pull this once it
goes through all the checks.
Doug
On Sunday, August 25, 2019 at 9:44:29 AM UTC-4, Marc Fehling wrote:
>
>
> I came up with a fix for this issue in the following PR #8637
> <https://github.com/dealii/d
succeeds for mpirun=4.release...
I have attached the output from ctest.
On Wednesday, August 21, 2019 at 5:39:11 AM UTC-4, Marc Fehling wrote:
>
> Hi Doug!
>
> On Wednesday, August 21, 2019 at 4:00:49 AM UTC+2, Doug wrote:
>>
>> 8134: void dealii::parallel::distr
ls (uncomment line 150) instead of
coarsening them (line 149), the solution transfer is successful. Playing
around with various refinement/coarsening, it seems a bit arbitrary when it
does work and when it won't. Am I calling anything out of order?
Doug
On Sunday, August 18, 2019 at 9:44:50 PM UTC-4
his.
How do you provide tests in the deal.II testsuite to account for different
round-off errors that might occur?
On Monday, August 19, 2019 at 1:17:10 PM UTC-4, Wolfgang Bangerth wrote:
>
> On 8/18/19 10:44 PM, Doug wrote:
> >
> > I'd be happy to add this test to the
x(), I wouldn't expect to do the
refinement for both DoF handlers at the same time.
I'd be happy to add this test to the list if that's something you are
interested in. I just have to take the time to read through how to.
Anyways, it all works as expected right now. Thank you again.
Doug
On Sunday,
to come up with the smallest possible program that still demonstrates
the error and contact the deal.II mailing lists with it to obtain help.
110:
I went through some of the deal.II source code and it's a bit out of my
depth. Please let me kno
your time. Hoping I can get up to speed to contribute
back in the future.
Best regards,
Doug
--
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 th
should produce optimal orders of convergence.
Thank you for the response, it was immensely helpful.
Doug
--
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
truly linear elements.
It's not really an issue for me since I will just switch to a
tensor-product basis. However, I am curious whether or not my understanding
of what is happening is correct, and if this behaviour is expected.
Best Regards,
Doug
--
The deal.II project is located at http
Hello Gary,
Since we have two independent implementation of DG, I am curious to know if
you achieve optimal error convergence order of (p+1) on *distorted* grids
for either linear advection, diffusion, or convection-diffusion.
Best Regards,
Doug
On Friday, April 26, 2019 at 11:48:58 AM UTC
and the Jacobian determinant to avoid re-computation. However, its
effect on the total time should be relatively small compared to flux
computations. "Premature optimization is the root of all evil".
Doug
On Sunday, February 10, 2019 at 2:15:04 PM UTC-5, Wolfgang Bangerth wrote:
>
>
>
abla_{reference} phi) every time reinit(cell) is called. Otherwise, the
solution will be to pre-compute and store those outside in some other
container and avoid using FEValues.
Doug
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://group
/I8aLPu5anrM/gBzaaqivDAAJ),
you plan on switching over to Tpetra, which will also be useful for us
since we might instantiate those vectors with AD types. Do you have an idea
of the time horizon on which this will be developped?
Doug
On Wednesday, February 6, 2019 at 9:22:17 AM UTC-5
integrators, I see that it looks relatively easy to template the
value type since it is already partially templated.
Is there a reason why those functions were not templated? Is there anything
we should be careful about before we start templating those functions?
Doug
--
The deal.II project
47 matches
Mail list logo
