On Jun 11, 2012, at 4:12 AM, Daniel Farrell wrote: > Thank you for suggesting a solution to the problem! Just so I understand: the > anchors are coefficients of source terms that are only non-zero in the edge > cells (left and right respectively) and they allow the problem to be restated > with flux=0 boundary conditions/constraints. It's not quite clear to me why > the huge 1e10 value is also needed?
The huge coefficient is so that the entries in the matrix at those boundary cells are completely dominated by the constraint. Otherwise, the solvers would be trying to find some compromise between the constraint and the other terms of the equation. > Out of interest why did the new constraints code have problems with this > example? For example, why does something like this not work? > > I_left_BC = I_left.getArithmeticFaceValue()[m.getInteriorFaces()][0] > I_right_BC = I_right.getArithmeticFaceValue()[m.getInteriorFaces()][-1] > I_right.constrain( A * I_left + C, where=m.getFacesLeft()) # x=0 BC > I_left.constrain( B * I_right, where=m.getFacesRight()) # x= It's the first thing I tried, but it seemed (unsurprisingly) to throw FiPy into an infinite loop. left depends on right, which depends on left, which depends on right, ... The dependencies aren't in the same place, but FiPy doesn't know that (and it would be really hard for it to figure it out). > Is there a way to write this problem using the very clear 'constraints' way > of doing things? Not that I could figure out, but I need to go back and look at some of my research codes, because I seem to remember coming up with a different way to do coupled boundary conditions with constraints. As I recall, it was messy, but there may be something there that can be generalized. _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
