Andrew Ho writes:
> I suppose that's true. The more I look at what Cubit/other meshing software
> generate at the surface, I don't think it can exactly represent even simple
> conics sections such as circular arcs and ellipses exactly, which is a
> shame.
True
> Still, I'd take 3rd order accura
> On Aug 24, 2016, at 8:07 PM, Harshad Ranadive
> wrote:
>
> Thanks a lot Barry for your help. I have resolved the issue of slow linear
> solver for excessively large RHS vectors to some degree.
>
> To summarize:
>
> 1) In my case, I wanted to solve the same linear system a large number of
Thanks a lot Barry for your help. I have resolved the issue of slow linear
solver for excessively large RHS vectors to some degree.
*To summarize:*
1) In my case, I wanted to solve the *same linear system a large number of
times for different RHS vectors*. Previously I was using the iterative
sol
Thanks for the help. I now understand why the DMDA local to global mapping
doesn’t work.
I was able to do what I wanted by computing the row/col numbers using natural
ordering and then converting to PETSc ordering using AOApplicationToPetsc and
the AO from DMDAGetAO, and that works fine.
Randy
How important is this matrix for performance? Is it just a side operation
you do rarely compared to linear solves and other stuff or is it used many
times in a tight loop?
If you do it rarely you can use a DMDAGlobalToNaturalBegin/End then do the
matrix product (and build the matrix) us
On Wed, Aug 24, 2016 at 5:01 PM, Randall Mackie
wrote:
> I already create my own matrix with the appropriate size and layout. The
> problem seems to be the local to global mapping from
> DMGetLocalToGlobalMapping, which I suspect does not allow for these
> non-local entries outside the stencil wi
>
> Correspondence should not be hard since you can mark the mesh however you
> like.
True, I guess I need to do this anyways in order to apply boundary
conditions.
If you are happy with quadratic surface approximations, then you are in a
> great spot here. However, I think its easy to push to a
I already create my own matrix with the appropriate size and layout. The
problem seems to be the local to global mapping from DMGetLocalToGlobalMapping,
which I suspect does not allow for these non-local entries outside the stencil
width.
How is one suppose to determine the local to global mapp
> On Aug 24, 2016, at 4:45 PM, Randall Mackie wrote:
>
> Well, I only need this particular matrix to multiply a vector (ordering based
> on the DMDA grid), so I don’t need to do any ghost communication (like
> residual calculations). I just need to be able to set a few non-local
> entries. Is
On Wed, Aug 24, 2016 at 4:45 PM, Randall Mackie
wrote:
> Well, I only need this particular matrix to multiply a vector (ordering
> based on the DMDA grid), so I don’t need to do any ghost communication
> (like residual calculations). I just need to be able to set a few non-local
> entries. Is the
Well, I only need this particular matrix to multiply a vector (ordering based
on the DMDA grid), so I don’t need to do any ghost communication (like residual
calculations). I just need to be able to set a few non-local entries. Is there
no way to do that without increasing the stencil width of t
> On Aug 24, 2016, at 4:27 PM, Randall Mackie wrote:
>
> I’ve run into a situation where MatSetValues seems to be dropping non-local
> entries. Most of the entries that are set are local, but a few are possibly
> non-local, and are only maximum a few grid points off the local part of the
> gr
I’ve run into a situation where MatSetValues seems to be dropping non-local
entries. Most of the entries that are set are local, but a few are possibly
non-local, and are only maximum a few grid points off the local part of the
grid.
Specifically, I get the local to global mapping, and the indi
On Wed, Aug 24, 2016 at 1:18 PM, Andrew Ho wrote:
> Philosophically it's certainly part of the job of the mesh generator, but
>> realistically I don't think there are any really viable high-order mesh
>> generators or even file formats right now (correct me if I'm wrong). And as
>> Matthew put, t
>
> Philosophically it's certainly part of the job of the mesh generator, but
> realistically I don't think there are any really viable high-order mesh
> generators or even file formats right now (correct me if I'm wrong). And as
> Matthew put, the mesh generator has no business telling us what our
Philosophically it's certainly part of the job of the mesh generator,
but realistically I don't think there are any really viable high-order
mesh generators or even file formats right now (correct me if I'm
wrong). And as Matthew put, the mesh generator has no business telling
us what our funct
That sounds like taking part of the job of the mesh generator and putting
it into my code. I was simply stating that without access to the original
geometric representation, I don't know if my simulation domain really has
flat walls, or even how curved are the walls if they are curved, so there's
n
On 08/24/2016 11:27 AM, Andrew Ho wrote:
Good geometric accuracy is very import for achieving appropriate
convergence rates in complex geometry, not just using higher order
polynomials on flat elements.
If you look at Hesthaven's book Nodal Discontinuous Galerkin Methods,
Table 9.1 shows that
True, Paraview does draw them in as "flat" edges, but this is less of a
concern for me; the important part is if I want to do a simulation on a
curved geometric model, I need to be able to achieve higher order numerical
accuracy because it reduces my simulation times by orders of magnitude.
On Wed
Good geometric accuracy is very import for achieving appropriate
convergence rates in complex geometry, not just using higher order
polynomials on flat elements.
If you look at Hesthaven's book Nodal Discontinuous Galerkin Methods, Table
9.1 shows that without support for curved elements, higher o
On Wed, Aug 24, 2016 at 1:22 PM, Matthew Knepley wrote:
> Notice that Paraview does exactly the wrong thing here in that it has
> straight lines connecting the midpoints and corners of the triangles.
>
Everytime I meet someone from Kitware, I complain about this and their
representation of quadr
On Wed, Aug 24, 2016 at 12:57 AM, Andrew Ho wrote:
> I created an unstructured tri6 mesh in Cubit and am trying to read it into
> PETSc using DMPlexCreateFromFile. However, when I do PETSc gives me an
> error that it doesn't support this type of element.
>
> I know my PETSc install has Exodus II
Matthew Knepley writes:
>> Yes, I do not support that since I think its a crazy way to talk about
>> things. All the topological information is in the Tri3 mesh, and
>> Cubit has no business telling me about the function space.
>>
>>
>> Do you support / plan to support curved elements?
>>
>
> I ha
On Wed, Aug 24, 2016 at 12:12 PM, Jed Brown wrote:
> Matthew Knepley writes:
> >> Yes, I do not support that since I think its a crazy way to talk about
> >> things. All the topological information is in the Tri3 mesh, and
> >> Cubit has no business telling me about the function space.
> >>
> >>
On Wed, Aug 24, 2016 at 10:45 AM, Boyce Griffith
wrote:
>
>
> On Aug 24, 2016, at 11:02 AM, Matthew Knepley wrote:
>
> On Wed, Aug 24, 2016 at 12:57 AM, Andrew Ho wrote:
>
>> I created an unstructured tri6 mesh in Cubit and am trying to read it
>> into PETSc using DMPlexCreateFromFile. However,
> On Aug 24, 2016, at 11:02 AM, Matthew Knepley wrote:
>
>> On Wed, Aug 24, 2016 at 12:57 AM, Andrew Ho wrote:
>> I created an unstructured tri6 mesh in Cubit and am trying to read it into
>> PETSc using DMPlexCreateFromFile. However, when I do PETSc gives me an error
>> that it doesn't supp
On Wed, Aug 24, 2016 at 12:57 AM, Andrew Ho wrote:
> I created an unstructured tri6 mesh in Cubit and am trying to read it into
> PETSc using DMPlexCreateFromFile. However, when I do PETSc gives me an
> error that it doesn't support this type of element.
>
Yes, I do not support that since I thin
27 matches
Mail list logo
