On Thu, Aug 9, 2012 at 10:02 AM, Colin McAuliffe <span dir="ltr"><<a href="mailto:cjm2176@columbia.edu" target="_blank">cjm2176@columbia.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sanjay, thanks for the reply but I am avoiding using blocked format since my problem has 10 dofs per node but only has either dofs 1-3 or 4-10 active on a particular node. If I use block the equations I run out of memory pretty quickly on my machine but can get to reasonable sized problems with the unblocked format.<br>
<br>
Matt, sorry I am not getting this, but I am still not sure how the DM interface works. I can see in the function PCFieldSplitSetDefaults that there is an initial call to DMCreateFieldDecomposition and subsequent calls to DMCreateSubDM based on the command line options. What I am missing is how the first call to DMCreateFieldDecomposition is able to figure out which equations belong to which field just from command line info such as -pc_fieldsplit_0_fields 2,0. Where/how are the fields 2 and 0 defined?<br>
</blockquote><div><br></div><div>That code is a little obscure because I am trying to be backwards compatible. I am going to remove DMCreateFieldDecompositionDM(). However,</div><div>right now, what it does is call DMCreateFieldDecompositionDM() but it overrides the result with DMCreateSubDM() if command line definitions are given.</div>
<div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks<br>
Colin<br>
<br>
<br>
Quoting Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Aug 9, 2012 at 9:21 AM, Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Colin,<br>
I you block the equations in FEAP, then the restrained BCs are<br>
'included' in assembled PETSc matrix (these dofs have rows that are zero<br>
modulo a value of unity on the diagonal and the restrained value on the<br>
right-hand side).<br>
<br>
</blockquote>
<br>
However, this is not necessary with the DM interface.<br>
<br>
Matt<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-sg<br>
<br>
On 8/9/12 8:41 AM, Colin McAuliffe wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From what I can gather from the petsc-dev source it looks like the<br>
commands in 4) will then generate the splits using strided blocks. The<br>
problem with that is the fortran code I am using (FEAP) uses petsc to<br>
assemble and solve the linear problem within its own nonlinear and time<br>
stepping schemes. The linear problem that petsc solves already has boundary<br>
conditions applied to it so petsc only sees the active (unrestrained)<br>
equations. So then in general fields can't be extracted from the active<br>
equations using strided blocks and I am stuck with generating the index<br>
sets defining the splits on my own. Will it still be possible to make use<br>
of the new DM functions in this case?<br>
<br>
FEAP website:<br>
<a href="http://www.ce.berkeley.edu/**projects/feap/" target="_blank">http://www.ce.berkeley.edu/**<u></u>projects/feap/</a><<a href="http://www.ce.berkeley.edu/projects/feap/" target="_blank">http://www.ce.<u></u>berkeley.edu/projects/feap/</a>><br>
<br>
Colin<br>
<br>
<br>
Quoting Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<br>
<br>
On Wed, Aug 8, 2012 at 10:51 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
<br>
On Wed, Aug 8, 2012 at 10:23 PM, Colin McAuliffe <<a href="mailto:cjm2176@columbia.edu" target="_blank">cjm2176@columbia.edu</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>wrote:<br>
<br>
Thanks all, regarding use of DM in 3.3, is the procedure now to create<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the fields with PCFieldSplitSetIS and then use<br>
DMCreateFieldDecompositionDM<br>
to create a new DM based from the new fields and the DM for the<br>
original<br>
problem?<br>
<br>
<br>
</blockquote>
1) Use petsc-dev<br>
<br>
2) PCFieldSplitSetIS() is independent. This allows you to define splits<br>
however you want, but then recursive gets harder<br>
<br>
3) In 3.3., it uses DMCreateFieldDecompositionDM() to split all fields<br>
apart at once<br>
<br>
4) In petsc-dev, it uses DMCreateSubDM() which can split off any<br>
combination of fields, which from the command line is something like<br>
<br>
-pc_fieldsplit_0_fields 2,0 -pc_fieldsplit_1_fields 1,3<br>
<br>
<br>
</blockquote>
I should have shown recursive:<br>
<br>
-fieldsplit_0_pc_type fieldsplit<br>
<br>
will split 2,0 into two blocks.<br>
<br>
Matt<br>
<br>
<br>
Matt<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Colin<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Colin McAuliffe<br>
PhD Candidate<br>
Columbia University<br>
Department of Civil Engineering and Engineering Mechanics<br>
<br>
<br>
</blockquote>
<br>
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which<br>
their<br>
experiments lead.<br>
-- Norbert Wiener<br>
<br>
<br>
</blockquote>
<br>
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which<br>
their<br>
experiments lead.<br>
-- Norbert Wiener<br>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
--<br>
------------------------------<u></u>**-----------------<br>
Sanjay Govindjee, PhD, PE<br>
Professor of Civil Engineering<br>
Vice Chair for Academic Affairs<br>
<br>
779 Davis Hall<br>
Structural Engineering, Mechanics and Materials<br>
Department of Civil Engineering<br>
University of California<br>
Berkeley, CA 94720-1710<br>
<br>
Voice: <a href="tel:%2B1%20510%20642%206060" value="+15106426060" target="_blank">+1 510 642 6060</a><br>
FAX: <a href="tel:%2B1%20510%20643%205264" value="+15106435264" target="_blank">+1 510 643 5264</a><br>
<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a><br>
<a href="http://www.ce.berkeley.edu/~**sanjay" target="_blank">http://www.ce.berkeley.edu/~**<u></u>sanjay</a> <<a href="http://www.ce.berkeley.edu/~sanjay" target="_blank">http://www.ce.berkeley.edu/~<u></u>sanjay</a>><br>
------------------------------<u></u>**-----------------<br>
<br>
<br>
</blockquote>
<br><span class="HOEnZb"><font color="#888888">
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which their<br>
experiments lead.<br>
-- Norbert Wiener<br>
<br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
<br>
-- <br>
Colin McAuliffe<br>
PhD Candidate<br>
Columbia University<br>
Department of Civil Engineering and Engineering Mechanics<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>