fix: an issue of established f-m connections being duplicated in the run time.

[Guotong-Ren]

This happens when the initial fracture is created without clear of the two vectors for stencil generation.

[paveltomin]

@CusiniM, @jhuang2601, and/or @rrsettgast please review

[Guotong-Ren]

initialNewFractureFields must take care of initial fracture created from execute() in SurfaceGenerator class. Otherwise, the duplication of f-m connections can happen afterwards. However, when there is a geomechanics initialization step, the previous "IF" will rule out stepping inside due to cycleNumber == 0.

[Guotong-Ren]

@CusiniM @paveltomin

[rrsettgast]

I think we need a more intricate initialization/initialcondition procedure to handle this cleanly.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 56.82%. Comparing base (93f0252) to head (0348dfa).
Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
...hysicsSolvers/multiphysics/HydrofractureSolver.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3466   +/-   ##
========================================
  Coverage    56.82%   56.82%           
========================================
  Files         1154     1154           
  Lines        99984    99983    -1     
========================================
+ Hits         56816    56818    +2     
+ Misses       43168    43165    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rrsettgast]

@Guotong-Ren
It isn't clear to me what exactly the problem is being addressed, or how the proposed change fixes the problem. Is there an example problem that you can point out to describe the issue and test the "fix"?

[Guotong-Ren]

@Guotong-Ren It isn't clear to me what exactly the problem is being addressed, or how the proposed change fixes the problem. Is there an example problem that you can point out to describe the issue and test the "fix"?

yes, if there is an initialization added before time = 0, the problem will emerge. For reference, you can take a look at the cases in this PR (#3285). When leak-off is dominant, fracture does not propagate and then mf connection will duplicate. @rrsettgast

[paveltomin]

@rrsettgast @CusiniM are you ok to merge this?

[rrsettgast]

Not sure this is a solid fix for the issue

[paveltomin]

Not sure this is a solid fix for the issue

Can the if statement be removed completely and just call that initialization unconditionally?

[Guotong-Ren]

Not sure this is a solid fix for the issue

Can the if statement be removed completely and just call that initialization unconditionally?

since the field initialization only takes effects when there are new fracture cells, i believe so.

[CusiniM]

Not sure this is a solid fix for the issue

Can the if statement be removed completely and just call that initialization unconditionally?

since the field initialization only takes effects when there are new fracture cells, i believe so.

Yeah, this should work. The lists should be empty so I would expect that function to do nothing.

[paveltomin]

Not sure this is a solid fix for the issue

Can the if statement be removed completely and just call that initialization unconditionally?

since the field initialization only takes effects when there are new fracture cells, i believe so.

Yeah, this should work. The lists should be empty so I would expect that function to do nothing.

thanks @CusiniM
@rrsettgast ?

[paveltomin]

@rrsettgast is it good for now or we still should be looking for a more fundamental fix?

[rrsettgast]

yeah. fine