View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001797 | OpenFOAM | Bug | public | 2015-07-23 15:48 | 2017-06-30 10:48 |
| Reporter | Assigned To | chris | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | GNU/Linux | OS | OpenSuSE | OS Version | 12.3 |
| Summary | 0001797: Extension of constraint boundary overrides | ||||
| Description | Current functionality allows limited override of constraint boundaries via the "patchType" keyword. This override is not however inherited by fields derived from the original field. Thus, for example, applying a fixedValue or zeroGradient boundary on a cyclicAMI via the override will not pass this setting to matrix fields H and A. Similarly new fields created via interpolation will lose the original override specification and revert to the default constrained type at the AMI location. This means that while boundaries derived from the underlying constraint type will in general behave correctly, any boundary that is not derived from the constraint type will produce inconsistencies. A modification of the original scheme to provide this functionality is proposed as follows: - provide constraint types (and via inheritance their derived classes) an identifier to allow for the application of constraint overrides that maintain the current behavior. This would do away with the current patchType override in favor of an identifier defined on the underlying constraint patchField. (Non-essential.) - re-purpose the patchType identifier or implement a new identifier to carry override specifications for non-derived patches on constraint boundaries. Extend GeometricField and fvPatchField constructors to allow passing of override types, similar to the mechanism currently in place for patch types in some Geometric field constructors. Modify appropriate GeometricField constructor instances (interpolation, A, H, etc) to support the extended override. The functionality described above would maintain the current convenience while enabling the solution of more unconventional (arbitrary) boundary combinations. This would allow (for instance) the solution of unconnected partial differential equations or equation sets in different parts of a single mesh. A simple example is conjugate heat transfer, where in conjunction with a zonal material properties implementation, much faster convergence of the thermal system can be achieved than with explicit region coupling. The fluid equations could perceive the constraint interface as a wall (discontinuity), while the thermal equations can be solved in the entire domain with only the diffusivity discontinuous. Several other usages can be envisioned: zonal LES/RANS, gate closure, localized multi-species transport, conjugate electromagnetic, coupled FSI, etc. | ||||
| Additional Information | We have successfully implemented a scheme similar to that described above and would be happy to contribute the relevant code modifications to the project. The only outstanding issue at present is the handling of overrides where constraint boundaries coincide with processor boundaries, which is currently circumvented via constrained decomposition in the case of parallel operation. | ||||
| Tags | No tags attached. | ||||
