2018-08-17 14:23 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002966OpenFOAM[All Projects] Bugpublic2018-06-13 10:52
Reportertniemi 
Assigned Towill 
PrioritylowSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Versiondev 
Target VersionFixed in Versiondev 
Summary0002966: Reacting parcels, using "none" as devolatilization model prevents surface reactions
DescriptionIf "none" is selected as devolatilization model, surface reactions can't happen because canCombust-flag will be false. NoDevolatilization-model will set the flag as true, but that code won't be reached, because the model reports itself as inactive and the check "if (!cloud.devolatilisation().active())" in ReactingMultiphaseParcel.C line 521 catches this.

Proposed fix: set the canCombust-flag true before returning from the active check (if canCombust != -1). Alternatively, remove the active=false functionality from the NoDevolatilization-model allowing the code to proceed to the calculate-step which sets the flag. However, this will cause a slight overhead due to the unnecessary computations in the calcDevolatilisation-function.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0009743

will (manager)

Sorry for the delay. This is not a bit of code that I am terribly familiar
with, and some of the logic is a bit circular. It seems to me that if the
devolatilization model ever sets canCombust to -1 then that disables the
devolatilization model, so the flag stays that way permenantly...

Is this the change you want?

--- a/src/lagrangian/intermediate/parcels/Templates/ReactingMultiphaseParcel/ReactingMultiphaseParcel.C
+++ b/src/lagrangian/intermediate/parcels/Templates/ReactingMultiphaseParcel/ReactingMultiphaseParcel.C
@@ -520,6 +520,10 @@ void Foam::ReactingMultiphaseParcel<ParcelType>::calcDevolatilisation
     // Check that model is active
     if (!cloud.devolatilisation().active())
     {
+ if (canCombust != -1)
+ {
+ canCombust = 1;
+ }
         return;
     }

~0009744

tniemi (reporter)

Yes, that would be what I'm suggesting. Sorry for not posting the patch myself.

Currently the canCombust behaves just like that, if it is ever set to -1, no devolatilization or surface reactions can happen after that. I have not personally used this functionality, but there is at least SuppressionCollision-model which can do this. Otherwise canCombust just tells when devolatilization has proceed far enough to allow surface reactions and setting it to 1 here allows surface reactions without any devolatilization model.

~0009745

will (manager)

Resolved in dev by commit 1fb11834
+Notes

-Issue History
Date Modified Username Field Change
2018-06-01 09:09 tniemi New Issue
2018-06-12 17:12 will Note Added: 0009743
2018-06-13 07:11 tniemi Note Added: 0009744
2018-06-13 10:52 will Assigned To => will
2018-06-13 10:52 will Status new => resolved
2018-06-13 10:52 will Resolution open => fixed
2018-06-13 10:52 will Fixed in Version => dev
2018-06-13 10:52 will Note Added: 0009745
+Issue History