<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Ed, I agree with you that there is a problem with how the interface is presented and guidelines need to be improved. That's why your feedback is so valuable - and we appreciate it. I created Table 12 (ref below) to make things more clear, but based on your
and others feedback is definitely not enough. We will take your input under serious advisement, but until we improve the process, here's some the rationale below in context.
<br>
</p>
<div class="moz-cite-prefix">On 8/31/20 7:32 PM, Ed Bueler wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Emil --
<div><br>
</div>
<div>When I use PETSc on various tasks, so far, I have separated (1) how I describe the problem structure for use by the PETSc component, and (2) the choice of solver. For TS I am confused about what is expected by the design you describe. I would like to
describe my ODE system as clearly as possible and *then* go out and try/choose solver types.</div>
<div dir="auto"><br>
</div>
</div>
</div>
</blockquote>
<p>I agree, I like to follow a similar process. But from implementation considerations this is sometimes difficult to maintain. ARKIMEX solves 6-7 different problems types ranging from stiff ODEs, IMEX ODEs, DAEs with or without trivial mass matrices. The decision
we made >5years ago was to keep a single TS type and code. The user should specify the F,G functions and tell PETSc the type of problem (ODE/DAE/Mass) and internally we'd distinguish as opposed to re-implementing the same code in 6-7 TS types with tiny differences.
<br>
</p>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div>My understanding is that if I have a problem which can be written in the form F(t,u,u') = G(t,u), and if I do not want to pre-emptively restrict to *not* allowing IMEX, then I should put F into an IFunction and G into a RHSFunction. This is a *good* split,
performance-wise, if in fact F contains the stiff part, but whether good or bad I have described the ODE system.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
In general yes, but if the ODE is implicit (e.g., nontrivial M), then from the solver standpoint there is no reason to put anything in G() because most solvers will move G on the other side and include in F. That's why CN, BE, BDF worked in your example. None
use G() explicitly. <br>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="auto">Any fully-implicit method should now be able to handle this form F(t,u,u') = G(t,u), because for implicit methods there is no real distinction between F(t,u,u')=0 and F(t,u,u')=G(t,u). If an IMEX method is completely flexible, and so far ROSW seems
to be flexible in this way (?), then I think it should also work with either form.</div>
<div dir="auto"><br>
</div>
</div>
</div>
</blockquote>
Ideally, yes. IMEX schemes for F(t,u,u')=G(t,u) and nontrivial M do not exist and special care is needed in order to account for that M that is buried inside F (Table 12). Exposing M as a separate object would make things easier on the user side on the surface
but would create issues for other users (e.g., those using ALE methods) and upset Jed :). ROSW does the same thing as the other implicit methods by moving G on the other side and becoming part of F; but it uses explicit evaluations of this fatter F. So although
you provide G, it is not treated separately by any of these methods.<br>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="auto">If an IMEX method is restricted further by form, e.g. requiring dF/d(u') to be the identity, then wouldn't it make sense to have the user programmatically indicate that structural property? Such an indication is not about the desired solver
but about the ODE. If the structural property held then we could proceed with the restricted-application method, e.g. ARKIMEX/EIMEX.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Perhaps one could have this (proposed) functionality:</div>
<div><br>
</div>
<div>TSSetLHSHasIdentity(TS,PETSC_TRUE)</div>
<div><br>
</div>
<div dir="auto">Or one might instead set an enumerate for whether dF/d(u') is I or M (invertible) or M (noninvertible for DAE) or a general nonlinear function:</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto">TSSetLHSStructureType(TS,TS_LHS_STRUCTURE_IDENTITY)</div>
</div>
<div dir="auto">TSSetLHSStructureType(TS,TS_LHS_STRUCTURE_INVERTIBLE)</div>
<div dir="auto">TSSetLHSStructureType(TS,TS_LHS_STRUCTURE_NONINVERTIBLE)</div>
<div dir="auto">TSSetLHSStructureType(TS,TS_LHS_STRUCTURE_NONLINEAR)<br>
</div>
<div dir="auto"><br>
</div>
<div>Obviously the enumerate would only need to include structure which some method could exploit.</div>
<div><br>
</div>
<div dir="auto">What do you think?</div>
<div dir="auto"><br>
</div>
</div>
</div>
</blockquote>
Yes, that is precisely why we introduced EquationType and this is what it does to some extent: EXPLICIT_ODE=LHS_STRUCTURE_IDENTITY IMPLICT_ODE=STRUCTURE_INVERTIBLE; DAE=STRUCTURE_NONINVERTIBLE, but then it can be DAE with different diff index. The idea was
to provide enough granularity that would be useful in a decision tree. But it has only been used consistently in the context of ARKIMEX because there it really makes a difference.<br>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="auto">In any case, I am currently having trouble with the preferred way to describe e.g. diffusion-reaction PDEs. It seems to me I would want to supply all four of these</div>
<div>IFunction</div>
<div>IJacobian</div>
<div>RHSFunction</div>
<div>RHSJacobian</div>
<div>so as to allow full-performance for both fully-implicit methods and IMEX methods. (And for typical examples I certainly *can* form RHSJacobian, for example.) But none of the src/ts/tutorials/ examples seem to unconditionally supply all four, and I can't
tell (e.g. from -ts_view) which parts are seen and called by the various methods.</div>
<div dir="auto"><br>
</div>
</div>
</div>
</blockquote>
<p>Yes, that's correct; all 4 are desirable if available/feasible. Unfortunately, for now I'd suggest iterating a bit between stage (1) and (2): what does the problem look like, what solvers I expect to use and what are the solver requirements. E.g., if you
have stiff-nonstiff IMEX and mass matrix that can be accelerated by ARKIMEX, then you'd need to work through the different functions until we put up a more reasonable guidance.
<br>
</p>
<p>I also think that ts_view is the perfect place to print information of what the solver actually solves based on the information is has. We'll try to formulate something like this. Examples can also be improved. Matt promised he'd some smarter partitioning
based on index sets that should make our lives easier.</p>
<p>Emil <br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAOHboJ-4y04xmseeE=tZ6UvqmES6dzQR-=XrYLqVw6WMKnZtug@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="auto">Ed</div>
<div><br>
<br>
</div>
</div>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 2:27 PM Constantinescu, Emil M. <<a href="mailto:emconsta@anl.gov" target="_blank" moz-do-not-send="true">emconsta@anl.gov</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div><br>
<br>
<p>On 8/31/20 12:17 PM, Ed Bueler wrote:<br>
<br>
<br>
</p>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr">Emil --<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Thanks for looking at this.</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
> Hi Ed, can you please add the following<br>
<br>
<br>
> TSSetEquationType(ts,TS_EQ_IMPLICIT);<br>
<br>
<br>
> before calling TSSolve and try again? This is described in Table 12 in the pdf doc.<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Yep, that fixes it. After setting the TS_EQ_IMPLICIT flag programmatically I get:</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
It is only programmatic because it has to do with the form of RHS and IFunctions.<br>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div>$ ./ex54 -ts_type arkimex -ts_arkimex_fully_implicit<br>
<br>
<br>
error norm at tf = 1.000000 from 12 steps: |u-u_exact| = 1.34500e-02<br>
<br>
<br>
</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
<div>Without -ts_arkimex_fully_implicit we still get the wrong answer, but, as I understand it, we expect the wrong answer because dF/d(dudt) != I, correct?</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
<p>Yes. I keep mixing F and G, but if you want to solve Mu'=H(u), then define the IFunction := M u_dot - H(u) then it should work with all time steppers.<br>
<br>
<br>
<br>
<br>
</p>
<br>
<br>
<p>If you want to set the RHS of your ODE in the RHS function (so that you can use explicit integrators, too) you have to provide:<br>
<br>
<br>
<br>
<br>
</p>
<br>
<br>
<p>IFunction := u_dot and RHSFunction := M^{-1}*H(u) [or solve Mx=H(u) in the RHS function].<br>
<br>
<br>
<br>
<br>
</p>
<br>
<br>
<p>Note that M u_dot - H(u) can only be solved by implicit solvers directly so IFunction := M u_dot and RHSFunction := H(u). Table 12 in the PDF doc explains these cases, but that can be improved as well.<br>
<br>
</p>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr"><br>
<br>
<div>So -ts_arkimex_fully_implicit does not set this flag?</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
No, its use is for when you have both IFunction (for stiff) and RHSfunction (for nonstiff) defined to solve Mu'=H(u) + W(u) and:<br>
<br>
<br>
<p>1- mass is identity: IFunction:= u_dot-H(u); RHSFunction:= W(u), or<br>
<br>
<br>
</p>
<br>
<br>
<p>2- mass is full rank, but not identity: IFunction:= M u_dot-H(u); RHSFunction:= M^{-1} * W(u)</p>
<br>
<br>
<p>and you have a choice of using either an IMEX scheme [-ts_arkimex_fully_implicit false] or just the implicit part [-ts_arkimex_fully_implicit true].<br>
<br>
<br>
</p>
<br>
<br>
<p>Thank you for your feedback on our short survey - it is very valuable in helping us crafting a less painful path to using all these options.</p>
<br>
<br>
<p>Emil<br>
<br>
<br>
</p>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr">> So that we improve our user experience, can you tell us what are your usual sources/starting points<br>
<br>
<div>> when implementing a new problem:<br>
<br>
<br>
> 1- PDF doc</div>
<br>
<br>
<div><br>
<br>
<br>
Yes. Looked briefly at the PDF manual. E.g. I saw the tables for IMEX methods but my eyes glazed over.</div>
<br>
<br>
<div><br>
<br>
<br>
> 2- tutorials (if you find a good match)<br>
<br>
<br>
<br>
<br>
<br>
</div>
<br>
<br>
<div>Yes. Looked at various html pages including the one for TSARKIMEX. But I missed the sentence "Methods with an explicit stage can only be used with ODE in which the stiff part G(t,X,Xdot) has the form Xdot + Ghat(t,X)." I did not expect that ARKIMEX<br>
<br>
had this restriction, and did not pick it up.<br>
<br>
<br>
<br>
<br>
<br>
> 3- own PETSc implementations<br>
<br>
<br>
<br>
<br>
<br>
Yes. I have my own diffusion-reaction system (<a href="https://github.com/bueler/p4pdes/blob/master/c/ch5/pattern.c" target="_blank" moz-do-not-send="true">https://github.com/bueler/p4pdes/blob/master/c/ch5/pattern.c</a>) in which ARKIMEX works well. (Or
at least as far<br>
<br>
as I can tell. I don't have a manufactured solution for it, for example.) I am in the midst of tracking down a different kind of error, probably from DMDA callbacks, when I got distracted by the current issue.<br>
<br>
<br>
<br>
<br>
<br>
> 4- online function doc<br>
<br>
<br>
<br>
<br>
<br>
Yes. See above comment on TSARKIMEX page. By my memory I also looked at the TSSet{I,RHS}Jacobian() pages, for example, and probably others.</div>
<br>
<br>
<div><br>
<br>
<br>
> 5- other</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Not sure.</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Thanks,</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Ed</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote"><br>
<br>
<div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 6:09 AM Constantinescu, Emil M. <<a href="mailto:emconsta@anl.gov" target="_blank" moz-do-not-send="true">emconsta@anl.gov</a>> wrote:<br>
<br>
<br>
</div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
<br>
<div><br>
<br>
<p><br>
<br>
<br>
</p>
<br>
<br>
<div>On 8/30/20 6:04 PM, Ed Bueler wrote:<br>
<br>
<br>
</div>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr">Actually, ARKIMEX is not off the hook. It still gets the wrong answer if told the whole thing is implicit:<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>$ ./ex54 -ts_type arkimex -ts_arkimex_fully_implicit # WRONG (AND REALLY SLOW)<br>
<br>
<br>
error norm at tf = 1.000000 from 224 steps: |u-u_exact| = 2.76636e+00<br>
<br>
<br>
<br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
Hi Ed, can you please add the following<br>
<br>
<pre width="80" style="font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;font-family:monospace;color:rgb(0,0,0)"> <a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSetEquationType.html#TSSetEquationType" style="font-family:monospace" target="_blank" moz-do-not-send="true">TSSetEquationType</a>(ts,<a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSEquationType.html#TSEquationType" style="font-family:monospace" target="_blank" moz-do-not-send="true">TS_EQ_IMPLICIT</a>);</pre>
<br>
<br>
<p>before calling TSSolve and try again? This is described in Table 12 in the pdf doc.<br>
<br>
<br>
</p>
<br>
<br>
<p><br>
<br>
<br>
</p>
<br>
<br>
<p>So that we improve our user experience, can you tell us what are your usual sources/starting points when implementing a new problem:</p>
<br>
<br>
<p>1- PDF doc</p>
<br>
<br>
<p>2- tutorials (if you find a good match)<br>
<br>
<br>
</p>
<br>
<br>
<p>3- own PETSc implementations</p>
<br>
<br>
<p>4- online function doc</p>
<br>
<br>
<p>5- other<br>
<br>
<br>
</p>
<br>
<br>
<p>Thanks,<br>
<br>
<br>
Emil<br>
<br>
<br>
</p>
<br>
<br>
<blockquote type="cite"><br>
<br>
<div dir="ltr"><br>
<br>
<div>versus</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>$ ./ex54 -ts_type arkimex # WRONG BUT IFunction IS OF FLAGGED FORM<br>
<br>
<br>
error norm at tf = 1.000000 from 16 steps: |u-u_exact| = 1.93229e+01<br>
<br>
<br>
</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>$ ./ex54 -ts_type bdf # RIGHT<br>
<br>
<br>
error norm at tf = 1.000000 from 33 steps: |u-u_exact| = 9.29170e-02<br>
<br>
<br>
</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>So I am not sure what "Methods with an explicit stage can only be used with ODE in which the stiff part G(t,X,Xdot) has the form Xdot + Ghat(t,X)." means.</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Ed</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote"><br>
<br>
<div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 2:57 PM Ed Bueler <<a href="mailto:elbueler@alaska.edu" target="_blank" moz-do-not-send="true">elbueler@alaska.edu</a>> wrote:<br>
<br>
<br>
</div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
<br>
<div dir="ltr">Darn, sorry.<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>I realize the ARKIMEX page does say "Methods with an explicit stage can only be used with ODE in which the stiff part G(t,X,Xdot) has the form Xdot + Ghat(t,X)." So my example does not do that. Is there a way for ARKIMEX to detect that dG/d(Xdot) = I?<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>Ed</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote"><br>
<br>
<div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 2:44 PM Ed Bueler <<a href="mailto:elbueler@alaska.edu" target="_blank" moz-do-not-send="true">elbueler@alaska.edu</a>> wrote:<br>
<br>
<br>
</div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
<br>
<div dir="ltr"><br>
<br>
<div>Dear PETSc --</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>I tried twice to make this an issue at the <a href="http://gitlab.com" target="_blank" moz-do-not-send="true">gitlab.com</a> host site, but both times got "something went wrong (500)". So this is a bug report by old-fashioned means.</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
I created a TS example, <a href="https://github.com/bueler/p4pdes-next/blob/master/c/fix-arkimex/ex54.c" target="_blank" moz-do-not-send="true">
<br>
<br>
https://github.com/bueler/p4pdes-next/blob/master/c/fix-arkimex/ex54.c</a> at my github, also attached. It solves a 2D linear ODE<br>
<br>
<br>
```<br>
<br>
<br>
x' + y' = 6 y<br>
<br>
<br>
y' = x<br>
<br>
<br>
```<br>
<br>
<br>
Pretty basic; the known exact solution is just exponentials. The code writes it as F(t,u,u')=G(t,u) and supplies all the pieces, namely IFunction,IJacobian,RHSFunction,RHSJacobian. Note both F and G must be seen by TS to get the correct solution. In summary,<br>
<br>
a boring (and valgrind-clean ;-)) example.<br>
<br>
<div><br>
<br>
<br>
For current master branch it runs fine for the fully-implicit methods (e.g. BDF, CN, ROSW) which can use the IFunction F, including with finite-differenced Jacobians. With BDF2, BDF2+-snes_fd, BDF6+tight tol., CN, BEULER, ROSW:<br>
<br>
<br>
$ ./ex54<br>
<br>
<br>
error norm at tf = 1.000000 from 33 steps: |u-u_exact| = 9.29170e-02<br>
<br>
<br>
$ ./ex54 -snes_fd<br>
<br>
<br>
error norm at tf = 1.000000 from 33 steps: |u-u_exact| = 9.29170e-02<br>
<br>
<br>
$ ./ex54 -ts_rtol 1.0e-14 -ts_atol 1.0e-14 -ts_bdf_order 6<br>
<br>
<br>
error norm at tf = 1.000000 from 388 steps: |u-u_exact| = 4.23624e-11<br>
<br>
<br>
$ ./ex54 -ts_type beuler<br>
<br>
<br>
error norm at tf = 1.000000 from 100 steps: |u-u_exact| = 6.71676e-01<br>
<br>
<br>
$ ./ex54 -ts_type cn<br>
<br>
<br>
error norm at tf = 1.000000 from 100 steps: |u-u_exact| = 2.22839e-03<br>
<br>
<br>
$ ./ex54 -ts_type rosw<br>
<br>
<br>
error norm at tf = 1.000000 from 21 steps: |u-u_exact| = 5.64012e-03<br>
<br>
<br>
<br>
<br>
<br>
But it produces wrong values with ARKIMEX:<br>
<br>
<br>
$ ./ex54 -ts_type arkimex<br>
<br>
<br>
error norm at tf = 1.000000 from 16 steps: |u-u_exact| = 1.93229e+01<br>
<br>
<br>
<div><br>
<br>
<br>
Neither tightening tolerance nor changing type (`-ts_arkimex_type`) helps ARKIMEX.<br>
<br>
<br>
<br>
<br>
<br>
Thanks!</div>
<br>
<br>
<div><br>
<br>
<br>
Ed</div>
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
<div>PS My book is at a late proofs stage, and out of my hands. It should appear SIAM Press in a couple of months. In all the examples in my book, only my diffusion-reaction system example using F(t,u,u') = G(t,u) is broken. Thus the motivation for a trivial<br>
<br>
ODE example as above.</div>
<br>
<br>
<div><br clear="all">
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
-- <br>
<br>
<br>
<div dir="ltr"><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div>Ed Bueler<br>
<br>
<br>
Dept of Mathematics and Statistics<br>
<br>
<br>
University of Alaska Fairbanks<br>
<br>
<br>
Fairbanks, AK 99775-6660<br>
<br>
<br>
306C Chapman<br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
</div>
<br>
<br>
<br clear="all">
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
-- <br>
<br>
<br>
<div dir="ltr"><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div>Ed Bueler<br>
<br>
<br>
Dept of Mathematics and Statistics<br>
<br>
<br>
University of Alaska Fairbanks<br>
<br>
<br>
Fairbanks, AK 99775-6660<br>
<br>
<br>
306C Chapman<br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
</div>
<br>
<br>
<br clear="all">
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
-- <br>
<br>
<br>
<div dir="ltr"><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div>Ed Bueler<br>
<br>
<br>
Dept of Mathematics and Statistics<br>
<br>
<br>
University of Alaska Fairbanks<br>
<br>
<br>
Fairbanks, AK 99775-6660<br>
<br>
<br>
306C Chapman<br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
<pre cols="72" style="font-family:monospace">--
Emil M. Constantinescu, Ph.D.
Computational Mathematician
Argonne National Laboratory
Mathematics and Computer Science Division
Ph: 630-252-0926
<a href="http://www.mcs.anl.gov/~emconsta" style="font-family:monospace" target="_blank" moz-do-not-send="true">http://www.mcs.anl.gov/~emconsta</a></pre>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
</div>
<br>
<br>
<br clear="all">
<br>
<br>
<div><br>
<br>
<br>
</div>
<br>
<br>
-- <br>
<br>
<br>
<div dir="ltr"><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div><br>
<br>
<div dir="ltr"><br>
<br>
<div>Ed Bueler<br>
<br>
<br>
Dept of Mathematics and Statistics<br>
<br>
<br>
University of Alaska Fairbanks<br>
<br>
<br>
Fairbanks, AK 99775-6660<br>
<br>
<br>
306C Chapman<br>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</div>
<br>
<br>
</blockquote>
<br>
<br>
<pre cols="72" style="font-family:monospace">--
Emil M. Constantinescu, Ph.D.
Computational Mathematician
Argonne National Laboratory
Mathematics and Computer Science Division
Ph: 630-252-0926
<a href="http://www.mcs.anl.gov/~emconsta" style="font-family:monospace" target="_blank" moz-do-not-send="true">http://www.mcs.anl.gov/~emconsta</a></pre>
<br>
<br>
</div>
<br>
<br>
<br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Ed Bueler<br>
Dept of Mathematics and Statistics<br>
University of Alaska Fairbanks<br>
Fairbanks, AK 99775-6660<br>
306C Chapman<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Emil M. Constantinescu, Ph.D.
Computational Mathematician
Argonne National Laboratory
Mathematics and Computer Science Division
Ph: 630-252-0926
<a class="moz-txt-link-freetext" href="http://www.mcs.anl.gov/~emconsta">http://www.mcs.anl.gov/~emconsta</a></pre>
</body>
</html>