[petsc-users] Reading data from a file into a DM created vector

[Matthew Knepley]

On Fri, Oct 31, 2014 at 4:15 PM, Justin Chang <jychang48 at gmail.com> wrote:

> Matt,
>
> Thanks for the response. One more question:
>
> If I go with approach 2, will manually setting the constraints/indices and
> its values be compatible with the DMPlexSNESComputeResidual/JacobianFEM
> routines? When I look at the source code of those routines it seems the
> constrained values are added to the local solution vectors via
> DMPlexInsertBoundaryValuesFEM. If I choose not to use DMPlexAddBoundary and
> wish to manually declare my boundary values, i assume I should call
> DMPlexProjectField with mode INSERT_BC_VALUES?
>

Yes, exactly. I use DMPlexProjectFunctionLabelLocal(),

https://bitbucket.org/petsc/petsc/src/ea1a9a653238fa98fb68e87b49145608ab6e5301/src/dm/impls/plex/plexfem.c?at=master#cl-576

  Thanks,

     Matt


> Thanks,
> Justin
>
> Sent from my iPhone
>
> On Oct 30, 2014, at 4:24 PM, Matthew Knepley <knepley at gmail.com> wrote:
>
> On Thu, Oct 30, 2014 at 4:16 PM, Justin Chang <jychang48 at gmail.com> wrote:
>
>> Matt, thanks for the quick response.
>>
>> What about for (dirichlet) boundary conditions? Would it be possible to
>> do something similar for those, like using those PetscSectionSetConstraint
>> functions?
>>
>
> Yes. There are generally two ways of handling Dirichlet conditions:
>
>   1) Replace those rows of the Jacobian with the identity and put the
> boundary value in the rhs. I find
>       this cumbersome for nonlinear solves.
>
>   2) Remove these unknowns from the system using
> PetscSectionSetConstraintDof() and ConstratinIndices().
>
> The DMPlexAddBoundary() functions are automating this processing by
> marking boundaries using DMLabels,
> and then constraining dofs on those boundaries.
>
>   Thanks,
>
>     Matt
>
>
>> Thanks,
>> Justin
>>
>> On Thu, Oct 30, 2014 at 3:35 PM, Matthew Knepley <knepley at gmail.com>
>> wrote:
>>
>>> On Thu, Oct 30, 2014 at 3:29 PM, Justin Chang <jychang48 at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> So I am writing an FEM code where it reads input data (e.g., auxiliary
>>>> coefficients, source terms, etc) from a text file. I have preprocessed the
>>>> data text file so that each vertex point has its corresponding data. For
>>>> instance, if my source term for a diffusion problem has a sin or cos
>>>> function of the coordinates, then this data is already tabulated and simply
>>>> needs to be fed into my PETSc program. The data text file containing both
>>>> the auxiliary data and the coordinate/connectivities will also be used to
>>>> provide the input arguments for the DMPlexCreateFromDAG() function.
>>>>
>>>> Normally, I would hard-code the sin/cos functions into the source code
>>>> itself, but i want my program to be "universal" in that it can take as
>>>> input any user-defined function for not only these auxiliaries but for
>>>> other things like boundary conditions. I see that PETSc has a lot of
>>>> examples on how to read data into vectors and matrices, but I guess my
>>>> question is is there a way to project data from a text file into a vector
>>>> that has already been created with a defined DM structure?
>>>>
>>>
>>> If you have the functions available, I think it is far more universal to
>>> use the function itself, since then you can be independent
>>> of mesh and discretization when specifying input and BC.
>>>
>>> However, if you want to read it in, and you guarantee that it matches
>>> the mesh and discretization, I think the easiest thing to do is
>>> demand that it come in the same order as the vertices and use
>>>
>>> VecGetArray(V, &a);
>>> for (v = vStart, i = 0; v < vEnd; ++v) {
>>>   PetscSectionGetDof(s, v, &dof);
>>>   PetscSectionGetOffset(s, v, &off);
>>>   for (d = 0; d < dof; ++d) a[off+d] = text_data[i++];
>>> }
>>> VecRestoreArray(V, &a);
>>>
>>>    Matt
>>>
>>>
>>>> Thanks,
>>>> Justin
>>>>
>>>
>>>
>>>
>>> --
>>> What most experimenters take for granted before they begin their
>>> experiments is infinitely more interesting than any results to which their
>>> experiments lead.
>>> -- Norbert Wiener
>>>
>>
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20141101/fab85ede/attachment.html>