Skip to content
Snippets Groups Projects

Draft: ENH: relative velocity usage for porosity in MRF regions

Closed Andrew Heather requested to merge feature-porous-mrf into develop

Related to #1652 - updates porosity calculation when used with MRF to use relative velocity

Test case from bug report: rotatingCylinders-test.tgz

Edited by Andrew Heather

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Andrew Heather changed milestone to %v2106

    changed milestone to %v2106

  • Andrew Heather added 223 commits

    added 223 commits

    Compare with previous version

  • added 7 commits

    Compare with previous version

  • Kutalmış Berçin marked this merge request as draft

    marked this merge request as draft

  • Kutalmış Berçin marked this merge request as ready

    marked this merge request as ready

  • Kutalmış Berçin changed title from Draft: WIP - relative velocity usage for porosity in MRF regions to ENH: relative velocity usage for porosity in MRF regions

    changed title from Draft: WIP - relative velocity usage for porosity in MRF regions to ENH: relative velocity usage for porosity in MRF regions

  • Please note that for the cases where "Using pressure implicit porosity" occurs, this set of commits will have no effect on velocity field. To this end, the formulation should/can be extended in future releases for implicit-porosity applications.

  • Kutalmış Berçin approved this merge request

    approved this merge request

  • added Ready label

  • Andrew Heather changed the description

    changed the description

  • @andy : Looking into this. I think there is a bit missing in the correction. the expression for drag is: Drag = D (Ua - Umrf) + 0.5Frho* mag(Ua - Umrf) * (Ua - Umrf)

    This is for a general the porous media pushing the flow as it moves or slowing the flow with drag.

    I think when you subtract :

    UEqn.source() -= Udiag*Uref - Usource;

    The first term seems correct , but the second is 0.5Frhosqr(Umrf), then the expression for drag is 0.5Frhosqr(Ua) - sqr(Umrf) when it should be sqr(Ua - Umrf) ?.

    The final result is actually the same as the converged result is similar as the flow is dragged by the MRF to a final state independently of the model expression. But for transient flow the behavior will be different.

    This could be done passing Umrf to apply function:

    const tensor Cd = mu[celli]*dZones[j] + (rho[celli]*mag(U[celli]))*fZones[j];

    const scalar isoCd = tr(Cd);

    const tensor Cd1 = mu[celli]*dZones[j] + (rho[celli]*mag(U[celli]-Umrf[celli]))*fZones[j];

    const scalar isoCd1 = tr(Cd1);

    Udiag[celli] += V[celli]*isoCd;

    Usource[celli] += -V[celli]isoCdUMrf[celli] (<-- this similar) -V[celli]((Cd1 - IisoCd1) & (U[celli]-Umrf[celli]);

    The end result is similar.

    For the implicit , not sure if we can have the exact expression in place for the second term of the Darcy model.

    What I did was similar to your with AU.

    tensorField AUmrf = 0 this->correct(UEqn, Umrf, AUmrf);

    UEqn.source() -= AUmrf*Uref

    The end result is similar. But the second term of the Darcy model is not correct. And i don't think it can be made implicit when solving for Uabs instead of Urel. WE can talk this over.

  • Andrew Heather marked this merge request as draft

    marked this merge request as draft

  • Author Owner

    The current implementation is wrong for some models - I've tagged as draft (so as not to merge) and will have a play.

    Edited by Andrew Heather
  • removed Ready label

  • Kutalmış Berçin unapproved this merge request

    unapproved this merge request

  • Kutalmış Berçin changed milestone to %v2112

    changed milestone to %v2112

  • Andrew Heather changed milestone to %v2212

    changed milestone to %v2212

Please register or sign in to reply