<div dir="ltr">Please squash the attached into your previous patch and test.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 2, 2013 at 11:39 PM, Richard Tran Mills <span dir="ltr"><<a href="mailto:rtm@eecs.utk.edu" target="_blank">rtm@eecs.utk.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jed (cc: petsc-dev, in case anyone else cares),<br>
<br>
As we discussed on gchat, if you will grab<br>
<br>
<a href="https://bitbucket.org/rmills/petsc-dev" target="_blank">https://bitbucket.org/rmills/<u></u>petsc-dev</a><br>
<a href="https://bitbucket.org/rmills/pflotran-dev" target="_blank">https://bitbucket.org/rmills/<u></u>pflotran-dev</a><br>
<br>
you can see what I have been trying to do to get DMShell usable for wrapping our PFLOTRAN unstructured grids in a DMs. All of the relevant PFLOTRAN changes are in discretization.F90. As a first step, I'm only trying to get the global-to-local operations working using DMs. I'm seeing the errors when I try to run a very simple unstructured grid problem in 'example_problems/umesh/usg_<u></u>5x4x3'. If I just run PFLOTRAN in there (one process, with no command-line arguments) it crashes with lots of complaints along the lines of<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[0]PETSC ERROR: PetscObjectGetFortranCallback(<u></u>) line 254 in /Users/rmills/proj/petsc-dev_<u></u>rmills/src/sys/objects/<u></u>inherit.c<br>
[0]PETSC ERROR: ourglobaltolocalend() line 80 in /Users/rmills/proj/petsc-dev_<u></u>rmills/src/dm/impls/shell/ftn-<u></u>custom/zdmshellf.c<br>
[0]PETSC ERROR: DMGlobalToLocalEnd() line 1668 in /Users/rmills/proj/petsc-dev_<u></u>rmills/src/dm/interface/dm.c<br>
</blockquote>
<br>
So it appears that I am doing something wrong. I will admit that so far I've just blindly emulated the examples you already had in zdmshellf.c and I haven't taken the time to digest how the new Fortran callback mechanism works, so maybe I'm just doing something dumb with that.<br>
<br>
On a somewhat related note, I've added a means to set a GlobalToLocal scatter context for the DMShell, which I do in the PFLOTRAN code, and the DMShellDefaultGlobalToLocalBeg<u></u>in/End, which just performs the scatter using that 'gtol' context that is stashed. I am setting the 'gtol' scatter and then specifying that the DMShellDefaultGlobalToLocalBeg<u></u>in/End be used. I suppose it makes more sense for the user to not have to set this if the 'gtol' has been given. Should I make the dm->ops->globaltolocalbegin point to DMShellDefaultGlobalToLocalBeg<u></u>in when the DMShell is created, and have that function check to see if the 'gtol' pointer is indeed set to something?<span class="HOEnZb"><font color="#888888"><br>
<br>
--Richard<br>
<br>
-- <br>
Richard Tran Mills, Ph.D.<br>
Computational Earth Scientist | Joint Assistant Professor<br>
Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences<br>
Oak Ridge National Laboratory | University of Tennessee, Knoxville<br>
E-mail: <a href="mailto:rmills@ornl.gov" target="_blank">rmills@ornl.gov</a> V: <a href="tel:865-241-3198" value="+18652413198" target="_blank">865-241-3198</a> <a href="http://climate.ornl.gov/~rmills" target="_blank">http://climate.ornl.gov/~<u></u>rmills</a><br>
<br>
</font></span></blockquote></div><br></div>