Issue 512 3D-1D coupling - #563
Conversation
…larify time argument
…nTotalModels, improve comment
…el initialization
…set_flowrates() for DIR
…et_bc_neu_l (pressure)
…D), fixes svZeroD DIR
…e DOFs from linear solve For 1D Dirichlet coupling, `iBC_Dir` is cleared in read_files.cpp so that set_bc_cpl routes the BC correctly. However this caused fsi_ls_ini to skip registering the face with the FSILS linear solver as a Dirichlet (BC_TYPE_Dir) constraint. As a result, the preconditioner did not zero out those rows/columns, and the linear solver overwrote the velocity values applied by set_bc_dir with the NS solution, producing a lower-than-expected centerline velocity (~47 vs ~63.66). Fix: detect Coupled-DIR faces in fsi_ls_ini and register them as BC_TYPE_Dir so their DOFs are properly excluded from Ax=b.
- CouplingInterfaceParameters: add Coupling_ramp_steps (int) and Coupling_ramp_ref_pressure (double) XML parameters - CoupledBoundaryCondition: add oned_ramp_steps_ / oned_ramp_ref_pressure_ private members with set_oned_ramp() / get_oned_ramp_steps() / get_oned_ramp_ref_pressure() accessors; propagate through all copy/move constructors and assignment operators - read_files.cpp: read ramp params from CouplingInterfaceParameters and store them in lBc.coupled_bc via set_oned_ramp() - svOneD_subroutines.cpp: OneDModelState gains ramp_steps, ramp_ref_pressure, step_count fields; init_svOneD reads them from coupled_bc; calc_svOneD applies linear pressure ramp for DIR coupling; step_count is incremented on every committed (BCFlag=='L') step
Implements exponential smoothing of the pressure boundary condition sent to the 1D solver (DIR coupling only): P_sent = omega * P_target + (1 - omega) * P_prev_sent where P_target has already been through the ramp filter. - Parameters.h/cpp: add Coupling_dir_relax_factor parameter (default 1.0) - CoupledBoundaryCondition.h/cpp: add oned_relax_factor_ field, getter, setter, copy/move and distribute() broadcast - read_files.cpp: parse and apply the new parameter - svOneD_subroutines.cpp: add relax_factor / P_prev_sent_old/new to OneDModelState; apply under-relaxation after ramp; update history only on BCFlag=='L' committed steps; NEU coupling untouched
ktbolt
left a comment
ktbolt
left a comment
There was a problem hiding this comment.
@taeoukkim A couple of general comments
- C++ does not have subroutines so rename
svOneD_subroutines*files tosvOneD_interface* - I see a lot of
sv1Dprefixes in the code; change these tosvOneD
michelebucelli
left a comment
michelebucelli
left a comment
There was a problem hiding this comment.
Thank you @taeoukkim, I have left some comments. I do apologize for the slight pedantry 😅 , I am happy to further discuss any of the comments I left, even over a call if necessary.
A couple of general comments:
-
as I pointed out in a few of my suggestions, I think that it would be useful to document a bit better how this works. This can be done by adding some details in the Doxygen comments and/or expanding those comments themselves. In some cases it might be enough to just point to the paper where the precise model/method used is implemented, as long as there is no ambiguity about it.
-
I think it might be useful to make an effort to further encapsulate the 1D-solver-related stuff into a coherent whole, and try to condense them into as few files as possible (and/or a few files placed in a dedicated folder). For example, some of the functions reside in the
svOneDnamespace, but many others do not, and I see no reason why they shouldn't.
javijv4
left a comment
javijv4
left a comment
There was a problem hiding this comment.
Hey @taeoukkim, thanks for working on this! I left some comments.
One important thing, the test case for the 1D implementation does not have all the necessary files to run. Can you update that?
Also, can you show tests for the Dirichlet implementation? I'm not sure whether they should be CI tests, but I think it would be helpful to show how to use the new functionality in the respective GitHub issues.
|
The svZeroD coupling code is not a good object-oriented implementation; had hoped the svOneD code could be implemented with a better design, perhaps implement an external solver abstract class of some sort, and then refactor the svZeroD code. @taeoukkim has used the current implementation as a template which was the most straight-forward thing to do. But now to implement a more object-oriented code we would need to refactor two codes; this should be a separate PR. |
ktbolt
left a comment
ktbolt
left a comment
There was a problem hiding this comment.
@taeoukkim Thank you for squashing your commits; much easier to review !
There was a problem hiding this comment.
Thanks for the many improvements @taeoukkim! I have done another pass (and also reopened some threads from previous pass)
|
Updated all commets again. New commit named 'thrid review change' |
…e functional error...
Current situation
resolves #512
Release Notes
New features:
(1) 3D–1D coupling for both Dirichlet and Neumann boundary conditions
(2) RCR boundary condition support with 0D/1D coupling interfaces
(3) Dirichlet-type 3D–0D coupling implemented
(4) Enabled simultaneous use of 1D and 0D coupling in a single model
Documentation
I will also update documentation.
Testing
Successfully compiled on macOS.
Tested with 3D–1D coupling cases.
Tested with mixed 3D–1D and 3D–0D coupling configurations.
Code of Conduct & Contributing Guidelines