Hypergraph #778
Hypergraph #778
Conversation
|
EDIT: numbers outdated, but results are still the same |
lkotipal
force-pushed
the
hypergraph
branch
2 times, most recently
from
deaaeec to
c97f20b
Compare
This reverts commit 4f0ccc5.
…ts' into hypergraph
| @@ -3637,8 +3644,8 @@ void initializeDataReducers(DataReducer * outputReducer, DataReducer * diagnosti | |||
| continue; | |||
| } | |||
| } | |||
| if(P::diagnosticWriteAllDROs || lowercase == "lbweight" || lowercase == "vg_lbweight" || lowercase == "vg_loadbalanceweight" || lowercase == "vg_loadbalance_weight" || lowercase == "loadbalance_weight") { | |||
There was a problem hiding this comment.
P::diagnosticWriteAllDROs lost here
ioread.cpp
Outdated
| success=readCellParamsVariable(file,fileCells,localCellStartOffset,localCells,"LB_weight",CellParams::LBWEIGHTCOUNTERX,3,mpiGrid); | ||
| } else { | ||
| success=readCellParamsVariable(file,fileCells,localCellStartOffset,localCells,"LB_weight",CellParams::LBWEIGHTCOUNTERX,1,mpiGrid); | ||
| success=success && readCellParamsVariable(file,fileCells,localCellStartOffset,localCells,"LB_weight",CellParams::LBWEIGHTCOUNTERY,1,mpiGrid); |
There was a problem hiding this comment.
is it really preferable to read the file three times instead of copying LBWEIGHTCOUNTERX into Y and Z?
There was a problem hiding this comment.
Probably not! It might actually even be a reasonable idea to leave counters Y and Z as zero, this should in principle reduce to using just the X counter even in 3D RCB? It does at least for all the norm reductions
There was a problem hiding this comment.
👍
Just rember to add a comment so we won't wonder why the other values are left at zero :)
| @@ -673,6 +673,15 @@ void SysBoundary::applySysBoundaryVlasovConditions( | |||
| SpatialCell::set_mpi_transfer_type(Transfer::CELL_PARAMETERS | Transfer::POP_METADATA | Transfer::CELL_SYSBOUNDARYFLAG, true); | |||
| mpiGrid.update_copies_of_remote_neighbors(SYSBOUNDARIES_EXTENDED_NEIGHBORHOOD_ID); | |||
|
|
|||
| // Mark cells that are communicating velocity blocks on system boundaries | |||
There was a problem hiding this comment.
Will this in fact now provide incorrect information to Zoltan? This tells it that a sysboundary cell which currently is not at a process boundary won't cost anything to communicate, even though in the end it would.
There was a problem hiding this comment.
This is not used for determining partitioning neighborhoods (see setPartitioningNeighborhoods in grid.cpp), just for data analysis of supposed communication weight from vlsv files.
vlasiator.cpp
Outdated
| mpiGrid[id]->parameters[CellParams::LBWEIGHTCOUNTER] *= 8.0; | ||
| for (int i = 0; i < 3; ++i) { | ||
| mpiGrid[id]->parameters[CellParams::LBWEIGHTCOUNTERX + i] *= 8.0; | ||
| } |
There was a problem hiding this comment.
Should CellParams::SYSBOUNDARIES_COMM also be *8 here?
(and returned afterwards)
There was a problem hiding this comment.
Nah, SYSBOUNDARIES_COMM is purely for data analysis, we don't need to set it when we're not writing.
vlasovsolver/vlasovmover.cpp
Outdated
| if (Parameters::prepareForRebalance == true) { | ||
| // Blocks need to be scaled to time since acceleration uses time |
There was a problem hiding this comment.
Except that currently we don't actually include the time from acceleration in the weight.
And using time here is IMO a Bad Idea(tm) because the thing being timed is calculateSpatialTranslation(), which includes all the MPI barriers, ghost updates, remote neighbour contributions etc.
There was a problem hiding this comment.
I think you are right, I can revert that crap. In any case it's just a matter of rescaling so shouldn't affect results.
loadBalance.partitioning_neighborhood, defaulting to the full neighborhood encompassing extended sysboundaries and Vlasov translation.loadBalance.norman arbitrary p-norm can be used, or usingnorm = 0the infinity/max-norm.weight_dim = 3enables multi-weight partitioning in Zoltan.