On Oct 20, 2014, at 9:03 AM, Gaaß, Markus <markus.ga...@zae-bayern.de> wrote:
> First of all thank you for FiPy! You're welcome. > I am trying to transfer a simulation that I used to run in Matlab using the > pdepe solver to FiPy. It models heat and mass transfer in a packed bed > reactor and uses the following system of differential equations > > i) eps_G * rho_G * du1/dt + m_G_dot * du1/dx > = - m_GS_dot > > ii) eps_S * rho_S * du2/dt > = m_GS_dot > > iii) eps_G * rho_G * c_P_G_ast * du3/dt + m_G_dot * c_P_G_ast * > du3/dx = q_GS_dot > > iv) eps_S * rho_S * c_P_S_ast * du3/dt > = - q_GS_dot + m_GS_dot * h_ads > > In FiPy I expressed this to my best knowledge as > > eqn1 = TransientTerm(coeff=eps_G*rho_G(u1), var=u1) + > ConvectionTerm(coeff=[m_G_dot,], var=u1) == -m_dot_GS(u1,u2,u3,u4) > eqn2 = TransientTerm(coeff=eps_S*rho_S, var=u2) == m_GS_dot(u1,u2,u3,u4) > eqn3 = TransientTerm(coeff=eps_G*rho_G(u1)*c_P_G_ast(u1), var=u3) + > ConvectionTerm(coeff=[m_G_dot*c_P_G_ast(u1),], var=u3) == q_dot_GS(u3, u4) > eqn4 = TransientTerm(coeff=eps_S*rho_S*c_P_S_ast(u2), var=u4) == > -q_GS_dot(u3, u4) + m_GS_dot(u1,u2,u3,u4) * h_ads(u2,u4) > > eqn = eqn1 & eqn2 & eqn3 & eqn4 > > You realize that some of the coefficients themselves depend on some or all of > the solution variables. > > Doing this and then calling “solve” for the combined equation like so > > for t in range(100): > u1.updateOld() > u2.updateOld() > u3.updateOld() > u4.updateOld() > eqn.solve(dt=1.e-3) > > I get an assertion error that I interpret as some vectors not being of equal > length > > 253 assert(len(id1) == len(id2) == len(vector)) This indicates that there's some problem in building the matrix. This assertion only happens when SciPy is being used for the solvers. It's possible (although I don't think so) that we don't support coupled solutions with SciPy. Can you try PySparse or Trilinos? > I would really appreciate help on the actual error but just a much also > general remarks on how this should be treated. > Although FiPy’s documentation is very extensive, in my case the factors of > being rather new to numerical methods and to python are a disadvantageous > combination that makes progress rather slow and weary. I went through the > examples but had the impression that something was always missing. Either > there was no convection term or there was no transient term or there was no > combined equation. What you are doing is OK, but presently there is no implicit coupling between the equations; eqn1 is only in terms of u1, eqn2 is only in terms of u2, etc. You have expressions like m_dot_GS(u1,u2,u3,u4) that are explicit functions of all variables, but that doesn't affect the matrix that's built; those terms all go to the right-hand-side. The result is a matrix that is block diagonal; that should solve, but doesn't gain anything over solving each of the equations in succession. In fact, try that: for t in range(100): u1.updateOld() u2.updateOld() u3.updateOld() u4.updateOld() eqn1.solve(dt=1.e-3) eqn2.solve(dt=1.e-3) eqn3.solve(dt=1.e-3) eqn4.solve(dt=1.e-3) Do you get any errors? _______________________________________________ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]