On Oct 20, 2014, at 9:03 AM, Gaaß, Markus <[email protected]> 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
[email protected]
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
