On Wed, Jul 22, 2009 at 3:57 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Matthew Knepley wrote:<br>
> No comments? Not even "This is complete shit!"?<br>
<br>
</div>Heh, it might be overkill and, if I understand you correctly, I think it<br>
could be a headache. There is a reasonable amount of code in the<br>
various interfaces to ensure some sequencing, but delayed evaluation is<br>
tough to reason about. When I call a function, I expect strict<br>
evaluation, but if you somehow store that call away until it's<br>
dependencies are satisfied, I'm likely to see confusing behavior.<br><div class="im"></div></blockquote><div><br>They way we resole this in configure is to have an "execute" function. I think<br>this would be pretty much the behavior people expect.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> On Tue, Jul 21, 2009 at 8:56 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
><br>
>> Actually, this seems like the same problem that Lisandro is having, just<br>
>> with<br>
>> different functions. I propose making data structures do the work for us<br>
>> rather than complicated organization in an imperative program.<br>
>><br>
>> We could use the same mechanism we use in configure to handle issues of<br>
>> object setup. We have a setup object that takes<br>
>><br>
>> a) an object to be setup<br>
>><br>
>> b) a set of functions to be called for setup, and<br>
>><br>
>> c) any functions which must be called prior to each given function<br>
<br>
</div>How would you specify these? In the general case, we have a partial<br>
ordering on setup functions. I suppose you are suggesting that any time<br>
you register a setup function, all dependencies would be given<br>
explicitly (hence added to the DAG, or referenced if they were already<br>
there).</blockquote><div><br>Yes, this pretty simple. Our interface is easy. Take a look at the configure<br>class Framework and the method require().<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It seems to me that we have rather few setup steps that require a<br>
particular sequence, some of which are not necessary. I would rather<br>
refactor to eliminate unnecessary dependencies than deal with delayed<br>
evaluation. If that looks especially complex, some dependency-handling<br>
object might help (probably just within the implementations for which it<br>
is necessarily complex), but I don't think it should be visible to the<br>
user.</blockquote><div><br>That object would not have to be seen. You would just have a<br><br> pc.require("SetSizes", m, n);<br> pc.require(...)<br> pc.setup()<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I think it would help to enumerate the dependencies that really are<br>
fundamental, and those that could (with work) be eliminated. Here's a<br>
start, I'm certainly missing some.<br>
<br>
Vec<br>
<br>
* sizes before type, not fundamental<br>
<br>
Mat<br>
<br>
* sizes before type, not fundamental, currently cached when type is<br>
"set" first which causes other problems<br>
* type before preallocation, fundamental<br>
<br>
KSP/PC<br>
<br>
* operators set before SetFromOptions, is this fundamental?<br>
* operators set before SetUp, fundamental<br>
<br>
SNES<br>
<br>
* function/Jacobian before SetFromOptions, is this fundamental?<br>
* function/Jacobian before SetUp, fundamental<br>
<br>
TS<br>
<br>
* similar to SNES<br>
<br>
<br>
Some cases, such as PC_ASM and PC_FieldSplit, would need different<br>
options management in order to set all the options in SetFromOptions.<br>
They create new matrices and KSP objects from the preconditioning matrix<br>
which doesn't exist before Solve/SetUp. It would be possible to move<br>
most of this into PCSetFromOptions_XXX if we could call<br>
KSPSetFromOptions before KSPSetOperators. It would also make it<br>
possible for the user to control these programmatically (currently the<br>
inner KSP cannot be created until solve, at which point it's too late<br>
for the user to manipulate it).<br>
<br>
Ideally we would have no dependencies between "personality" (types and<br>
options) and "mechanics" (for lack of a better term -- sizes, operators,<br>
preallocation). The former can influence the latter (changing the type<br>
changes the mechanics), but I think a mandatory ordering is bad (except<br>
where necessary, setting an option for a specific type obviously must<br>
happen after that type is set)</blockquote><div><br>This already sounds needlessly complicated to me. It also sounds like we are<br>introducing this complication because the language stinks, not because we<br>have not figured out an easy way to do it (which we already use elsewhere for<br>
the exact same purpose).<br><br> Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
Jed<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <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>