Skip to content

Commit

Permalink
fix for 0 input wind speed momentum solver cases, just skip running s…
Browse files Browse the repository at this point in the history 
…impleFoam entirely for 0 input wind speed cases, skip directly to sampling from the initial values time directory without dealing with simpleFoam error passing

Note that all I did for this commit, was wrap the if(\!SimpleFoam()) if statement with another if statement if( input.inputSpeed \!= 0 ), all the rest of the changes are just indentations, which git does not handle describing very well.

for issue #526
  • Loading branch information
@latwood
latwood committed Aug 23, 2024
1 parent a624325 commit 345bce3
Showing 1 changed file with 40 additions and 36 deletions.
76 changes: 40 additions & 36 deletions src/ninja/ninjafoam.cpp
View file
Original file line number Diff line number Diff line change
Expand Up @@ -293,49 +293,53 @@ bool NinjaFoam::simulate_wind()

input.Com->ninjaCom(ninjaComClass::ninjaNone, "Solving for the flow field...");
int status = 0;
if(!SimpleFoam()){
if(input.existingCaseDirectory == "!set"){
//no coarsening if this is an existing case
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). Can't coarsen "
"mesh for existing case directory. Try again without using an existing case.");
return false;
}
//try solving with previous mesh iterations (less refinement)
while(latestTime > 50){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). Coarsening mesh...");
CPLDebug("NINJAFOAM", "unlinking %s", CPLSPrintf( "%s/%d", pszFoamPath, latestTime ));
NinjaUnlinkTree( CPLSPrintf( "%s/%d", pszFoamPath, latestTime ) );
if(input.numberCPUs > 1){
for(int n=0; n<input.numberCPUs; n++){
NinjaUnlinkTree( CPLSPrintf( "%s/processor%d", pszFoamPath, n) );
}
// skip and go directly to sampling from the initial conditions case directory if a zero input wind speed case

This comment has been minimized.

Sign in to view

Copy link
@nwagenbrenner

nwagenbrenner Sep 6, 2024

Member

@latwood I'm not sure this works. It looks like ReconstructPar() will still be called if input.inputSpeed == 0.0.

This comment has been minimized.

Sign in to view

Copy link
@nwagenbrenner

nwagenbrenner Sep 6, 2024 •
edited
Loading

Member

I don't think this works. the sampling routines are still called if input.inputSpeed == 0.0, but if simpleFoam() isn't run so there won't be anything to sample. I think what we need to do is just bypass all of the OpenFOAM stuff and run just the diurnal portion if the user requests an input speed of 0.0 and has diurnal turned on. Maybe there should be a check for this earlier on so we create a ninja and not a ninjafoam for that case.

This comment has been minimized.

Sign in to view

Copy link
@latwood

latwood via email Sep 6, 2024

Author Collaborator

This comment has been minimized.

Sign in to view

Copy link
@latwood

latwood via email Sep 6, 2024

Author Collaborator

This comment has been minimized.

Sign in to view

Copy link
@nwagenbrenner

nwagenbrenner Sep 6, 2024

Member

@latwood No, I'm saying make a ninja instead of a ninjafoam instance if the user tries to do a cfd run with 0 input speed but with diurnal. That should simplify things -- we'll just do whatever we would do if it was a mass run with 0 input wind speed and diurnal. Do the check in ninjaArmy probably (or the GUI or CLI if we have to).
if( input.inputSpeed != 0 )

This comment has been minimized.

Sign in to view

Copy link
@nwagenbrenner

nwagenbrenner Sep 6, 2024

Member

@latwood We should make this check on a double, right? input.inputSpeed != 0.0
{
if(!SimpleFoam()){
if(input.existingCaseDirectory == "!set"){
//no coarsening if this is an existing case
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). Can't coarsen "
"mesh for existing case directory. Try again without using an existing case.");
return false;
}
latestTime -= 1;
meshResolution *= 2.0;
CPLDebug("NINJAFOAM", "stepping back to time = %d", latestTime);
//try solving with previous mesh iterations (less refinement)
while(latestTime > 50){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). Coarsening mesh...");
CPLDebug("NINJAFOAM", "unlinking %s", CPLSPrintf( "%s/%d", pszFoamPath, latestTime ));
NinjaUnlinkTree( CPLSPrintf( "%s/%d", pszFoamPath, latestTime ) );
if(input.numberCPUs > 1){
for(int n=0; n<input.numberCPUs; n++){
NinjaUnlinkTree( CPLSPrintf( "%s/processor%d", pszFoamPath, n) );
}
}
latestTime -= 1;
meshResolution *= 2.0;
CPLDebug("NINJAFOAM", "stepping back to time = %d", latestTime);

/* update simpleFoam controlDict writeInterval */
UpdateSimpleFoamControlDict();
/* update simpleFoam controlDict writeInterval */
UpdateSimpleFoamControlDict();

input.Com->ninjaCom(ninjaComClass::ninjaNone, "Applying initial conditions...");
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Applying initial conditions...");

ApplyInit();
ApplyInit();

if(input.numberCPUs > 1){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Decomposing domain for parallel flow calculations...");
DecomposePar();
if(input.numberCPUs > 1){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Decomposing domain for parallel flow calculations...");
DecomposePar();
}
status = SimpleFoam();
if(status == true){
break;
}
}
status = SimpleFoam();
if(status == true){
break;
//if the solver fails with latestTime = 50 (moveDynamicMesh mesh), we're done
if( status == false & latestTime == 50 ){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). The flow solution failed.");
return false;
}
}
//if the solver fails with latestTime = 50 (moveDynamicMesh mesh), we're done
if( status == false & latestTime == 50 ){
input.Com->ninjaCom(ninjaComClass::ninjaNone, "Error during simpleFoam(). The flow solution failed.");
return false;
}
}
} // if(!SimpleFoam())
} // if( input.inputSpeed != 0 )
CPLDebug("NINJAFOAM", "meshResolution= %f", meshResolution);

if(input.numberCPUs > 1){
Expand Down

2 comments on commit 345bce3

@latwood
Copy link
Collaborator Author

@latwood latwood commented on 345bce3 Sep 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally revisited this, at least studying it, with the intent of doing a small change and being done, but I think it's more complicated than I was thinking to move this check to the ninjaArmy code.

If I'm understanding correctly, ninjaArmy makes an army, setting the ninjas to be ninjas or ninjafoam ninjas, one constructor per initialization type, domainAvg, pointInitialization, weatherModel. PointInit currently only runs on ninjas and not ninjafoam ninjas, so then in theory the lines of code to edit would be here for a domainAvg run ([https://github.com/firelab/windninja/blob/421a78e8787c4ed0f1d5e06bde77275b80b6c081/src/ninja/ninjaArmy.cpp#L57]), and here for a wxModel run ([https://github.com/firelab/windninja/blob/421a78e8787c4ed0f1d5e06bde77275b80b6c081/src/ninja/ninjaArmy.cpp#L283]), can leave the pointInit makeArmy code the same. Then ninjaArmy startRuns() would automatically treat the diurnal momentum solver ninjas of 0 wind speed as regular ninjas and diurnal momentum solver ninjas of >0 wind speed as ninjafoam ninjas, though would need to watch out for these types of if statements checking against ninja[0] now that you can have differing types of ninjafoam ninjas and regular ninjas in a list ([https://github.com/firelab/windninja/blob/421a78e8787c4ed0f1d5e06bde77275b80b6c081/src/ninja/ninjaArmy.cpp#L629]).

If I'm understanding correctly, other than minor debugging for ninja[0] vs ninja[i] stuff, ninjaArmy startRuns() should then do the proper code runs depending on the already input ninja type. But, if I'm understanding correctly, setting the ninja types with something like an input wind speed == 0.0, in those above lines of makeArmy code, is actually not as easy to do as I originally thought, we don't even have a consistent input wind speed selected yet by that time to use for the check yet?, and even if we did, I'm not even sure that we have access to WindNinjaInputs to get such values for such a check. NinjaArmy sets such values to WindNinjaInputs within the ninjas, but doesn't seem to have get type stuff, plus the ninjas are in the process of being created in those lines of code.

Anyhow, with a domainAvg run, since it IS just an input wind speed, probably can just somehow figure out how to get such a wind speed and use it directly. For the wxModel runs, seems like a 0 wind speed case is pretty rare, but I'm not even sure how you would get or process such a wind speed without letting the code run further. Maybe if there is some kind of intermediate function after makeArmy() but before or at the start of startRuns() that uses the already premade ninjas from makeArmy() be made and so processing whatever they process to get a given input wind speed value, but then now remakes those ninjas into new ninjas of the correct type using that calculated wind speed? Just still feels a bit off, because are the input wind speeds even set for wxModel runs for ninjafoam simulations until after the call to simulateWind()?

Like I said, I might be misunderstanding. But it does seem like the order of when and how we have information is a bit skewed in this process when doing it within makeArmy() instead of handling it within the ninjafoam ninja itself in the moment.

@latwood
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems I was correct about not yet having input.inputSpeed even set by the point of ninjaArmy construction, the constructed ninjas from ninjaArmy construction then are called in cli or elsewhere to set the input.inputSpeed values, where you have to call the constructed ninjas themselves to get the input values.

But by the start of ninjaArmy startRuns(), the values are set, I seem to be able to reset the ninjas to the new type right at the start of ninjaArmy startRuns() and before startRuns() stuff. That being said, I'm still running into some walls because of the way some values are not yet set for passing on from a ninjafoam ninja to a regular ninja till after simulateWinds() is called, for example meshResolution. Besides meshResolution, there is something else that is causing the updated ninjas to seg fault at the output writer step that I still have to track down.

Anyhow, don't want to forget, after this fix works for a single ninja case, need to update the regular startRuns() stuff to handle varying types of ninjas in a set of ninjas.

I will likely only add future comments on this problem to future commits.

Please sign in to comment.