Hi Ian,
Sorry for the slow response.
On Wed, Sep 7, 2016 at 5:57 PM, Campbell, Ian
wrote:
>
> Firstly, the FiPy code I’m working with sweeps for four inter-dependent
> CellVariables / PDEs in a loop until their residuals falls below specified
> tolerances. After profiling the code, it’s clear that this sweeping process
> accounts for ~95% of the time spent solving in a given timestep.
> Consequently, advancing in time is painfully slow. Assuming that the
> CellVariable tolerances are fixed at their largest allowable values, what
> would be the best strategy for me to take to reduce the time spent sweeping
> these variables?
I'm surprised that it's only 95%, it should be closer to 100% as
that's mostly all that happens in any given time step. The sweep
consists of the matrix build and the linear solve. That's the
proportion that you want to understand. Best to profile to see how
long the linear solution is as a proportion of the overall sweep time
and work from there. Then you can then focus your attention on
improving either the linear solve or improving the coefficient
calculations (using --inline for instance) depending on what's slow or
see if there is a calculation (e.g. whether you use numpy.maximum or
max can make a huge difference) that is spending the bulk of the time.
> Secondly, some (but not all) of the boundary conditions for these four PDEs
> need to be updated between sweeping one CellVariable and the next. Notably,
> this is within a single timestep because the boundary conditions are
> functions of the CellVariables being swept. What is the recommended approach
> for updating the values of these boundary conditions, and why?
If the boundary conditions values are defined as variables then they
should automatically update themselves or you can update them during
the sweep manually with some code if you don't trust the lazy
evaluation. Either way that is an explicit approach to updates and
will probably have some limitation in the time step. If you can build
implicitness into the boundary conditions then that could save you on
the time step restriction, but this is highly problem dependent. I
think it's best to have a concrete example.
> At present,
> the following is the approach used: define the boundary condition only
> within the loop using x.constrain(value, where=some_boundary). i.e. the
> boundary condition is re-defined with new variables at every pass through
> the loop.
My feeling is that if "value" is an expression involving other
variables then it will update automatically so you won't have to keep
redefining the constraint during the loop. I think whatever approach
you use it shouldn't be necessary to redefine the same constraint over
and over. There could be a lot wrong with that approach. You can
always make "value" a variable and update it's value explicitly in the
loop rather than redefining the constraint.
> However, I suspect that this approach may be incorrect, and that a better
> approach may be to define the boundary conditions only once, outside of the
> loop, and to update them by employing the .value approach for CellVariables.
> I am at a loss to understand why this approach may be better, though.
Yup. It's just that you might be defining many constraints for a
CellVariable. Are they updated or do they all apply or what? I'm not
sure, but I don't think they were designed to work like that. Have you
tried defining the constraint once and updating the variable's value?
Does it give the same results?
Cheers,
Daniel
--
Daniel Wheeler
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
