-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Temperature dependent Thermal Expansion Coefficient #3185
base: develop
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3185 +/- ##
===========================================
+ Coverage 56.82% 57.18% +0.35%
===========================================
Files 1154 1159 +5
Lines 99983 100133 +150
===========================================
+ Hits 56818 57263 +445
+ Misses 43165 42870 -295 ☔ View full report in Codecov by Sentry. |
5fe7e2f
to
f9c5e54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, Sy Tuan.
LvArray::tensorOps::symAddIdentity< 3 >( totalStress, thermalStressIncrement ); | ||
|
||
// Save rock stress including the contribution of temperature change. | ||
m_solidUpdate.saveStress( k, q, totalStress ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice change for computing effective stress to include thermal component.
Hello @rrsettgast and @CusiniM, this PR is almost ready for merge and would appreciate if you take a final review. |
This failure is always reported for
The problem is being handled by #3387 |
real64 dThermalExpansionCoefficient_dTemperature; | ||
real64 thermalExpansionCoefficient; | ||
|
||
if( m_drainedTECTableName == nullptr || m_drainedTECTableName[0] == '\0' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's happening here? This seems hacky and it's in a device function...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is a hack to pass the GPU build after many trials & errors. It is welcome if you have another solution that is more suitable to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this trying to achieve? Can you present to us at one of the dedicated dev meetings what you are trying to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe cast m_drainedTECTableName
into a bool on host and then pass the bool to PorousSolidUpdates
.
@@ -121,11 +133,31 @@ class SolidBaseUpdates | |||
* @return the thermalExpansionCoefficient of element k | |||
*/ | |||
GEOS_HOST_DEVICE | |||
real64 getThermalExpansionCoefficient( localIndex const k ) const | |||
virtual real64 getThermalExpansionCoefficient( localIndex const k ) const |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you want this to be virtual? It's okay if you are just trying to enforce that function is implemented everywhere but keep in mind that there are no vtables on device. These functions can't be used as proper virtual functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
virtual
is added to make it consistent with the existing getters of bulk and shear moduli.
// Test that the default TEC derivative w.r.t. temperature and the default reference temperature are nil. | ||
EXPECT_DOUBLE_EQ( updates.m_dThermalExpansionCoefficient_dTemperature, 0 ); | ||
EXPECT_DOUBLE_EQ( updates.m_referenceTemperature, 0 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need these tests? I mean having self-contained tests for the constitutive models is a good idea but it's unclear to me why you need to test this. Aren't you assigning this as default value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These unit tests were added to pass one of the CI build that requires to cover a certain % of the code. Again, I am totally ok if you have another option that is more suitable to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that CI test is not mandatory for merging.
…ub.com/GEOS-DEV/GEOS into feature/sytuan/temperatureDependentTEC
static constexpr char const * dThermalExpansionCoefficient_dTemperatureString() { return "dDrainedTEC_dT"; } | ||
static constexpr char const * referenceTemperatureString() { return "referenceTemperature"; } | ||
|
||
static constexpr char const * drainedTECTableNameString() { return "drainedTECTableName"; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a validator here. To ensure that if the user provides a table name, then the relevant TableFunction
exists.
using namespace geos; | ||
using namespace ::geos::constitutive; | ||
|
||
TEST( CeramicDamageTests, testThermalExpansionAndTemperature ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expected this to test some of the kernel functions. Is there a plan for that perhaps?
This PR implement the non-linear Thermo-Elastic behavior related to non constant Thermal Expansion Coefficient (TEC). Either a linear law or a table could be considered for defining TEC vs Temperature.