MercuryDPM  Beta
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Pages
Todo List
Class AdhesiveForceSpecies
Should we rename AdhesiveForce to ShortRangeNormalForce or NonContactNormalForce?
Author
weinhartt
Member AngledPeriodicBoundary::checkBoundaryAfterParticleMoved (BaseParticle *P, ParticleHandler &pH UNUSED)
{TW: can't we do the shift in the createPeriodicParticles function only? We are checking the distance three times!}
Member AngledPeriodicBoundary::set (Vec3D normalLeft, Vec3D normalRight, Vec3D origin)
{TW: I cannot calculate angular shift; right now this works only for quarter
Member AngledPeriodicBoundary::shiftPosition (BaseParticle *P)

add velocity, angular, springs shift

{TW: not sure how to calculate the angular position in common_axis direction}

tangential spring

Member AngledPeriodicBoundary::shiftPositions (Vec3D &P1, Vec3D &P2)
TW: this still doesn't shift all data
Member AxisymmetricIntersectionOfWalls::getInteractionWith (BaseParticle *P, Mdouble timeStamp, InteractionHandler *interactionHandler) final
{DK: What is the contact point for interactions with walls}
Member BaseHandler< T >::BaseHandler (const BaseHandler< T > &BH)
Should max objects be set to the number of objects after this constructor? Maybe in copyContentsFromOtherHandler?
Class BaseInteractable
Check prescribed objects have infinite mass.
Member BaseInteractable::BaseInteractable ()

TW: why do some constructors (e.g. BaseInteractable, BaseParticle)not explicitly call the constructor from the inherited class?

Member BaseInteractable::getInteractionWith (BaseParticle *P, Mdouble timeStamp, InteractionHandler *interactionHandler)=0

TW make sure this function sets normal, distance, overlap, contact point

AT why is this a BaseParticle and not a BaseInteratable.

Member BaseInteractable::getOrientation () const
This is not full implemented and is related to quaterians.
Returns
Returns a reference to a Vec3D returns the position of the interactable.
Member BaseInteraction::copySwitchPointer (const BaseInteractable *original, BaseInteractable *ghost) const
Can this be simpler if we replace the particle with the ghost.
Parameters
[in]originalBaseInteractable* to the original particles who periodic image is being created from.
[in]ghostBaseInteractble* to the new ghost (periodic partcles) that has just been created.
Member BaseInteraction::gatherContactStatistics ()

Thomas please document this; as this is the area you are currently rewriting.

Thomas please document.

TW centre is used just for backward compatibility; replace centre by contact law; we also have to correct it in StatisticsVector::gatherContactStatistics. There also seems to be an issue with the normal being defined differently for walls

Member BaseInteraction::getAbsoluteNormalForce () const
Ant: Check this comment.
Returns
Mdouble that contains the absolute norm (length) of the normal force.
Member BaseInteraction::getNormalRelativeVelocity () const
Ant: Check this comment.
Returns
Mdouble that contains the norm (length) of the relative velocity.
Member BaseInteraction::integrate (Mdouble timeStep)
Ant: When is this case; is there an examepl?
Member BaseInteraction::rotateHistory (Matrix3D &rotationMatrix)
some of these might be unneccesary
Member BaseInteraction::write (std::ostream &os) const
should we output id's here? os << " id " << getId() << " particleIds " << P_->getId() << " " << I_->getId();
Member BaseInteraction::writeToFStat (std::ostream &os) const

TW centre is used just for backward compatibility; replace centre by contact law; we also have to correct it in StatisticsVector::gatherContactStatistics. There also seems to be an issue with the normal being defined differently for walls

the flip in normal/tangential direction for walls should not be done; this is an old bug

Member BaseObject::setId (const unsigned int id)
TW: here we should update BaseHandler::nextId_
Member BaseParticle::getDisplacement2 (Mdouble xmin, Mdouble xmax, Mdouble ymin, Mdouble ymax, Mdouble zmin, Mdouble zmax, Mdouble t) const

see .cc file.

Rewrite, redefine (TW). Is only used in StatisticsVector.hcc, consider moving to that class.

Member BaseParticle::getInteractionWith (BaseParticle *P, Mdouble timeStamp, InteractionHandler *interactionHandler)
We should consider setting the contact point to r=P->getRadius()/(getRadius+P->getRadius()) P->getPosition() - (P->getRadius() - ratio * C->getOverlap()) * C->getNormal()
Author
weinhartt
Member BaseParticle::integrateBeforeForceComputation (double time, double timeStep)
If the position is described by the used, one should also call BaseInteractabld::integrateBeforeForceComputation. To check if it works correctly, remove the p0.fixParticle() line from the DrivenParticleUnitTest
Author
irana
Member BaseParticle::invMass_
{TW: why do we need to store mass and inertia; can we take it out?}
Member BaseParticle::oldRead (std::istream &is)
{fix this function} IFCD: what is broken about it?
Member BaseParticle::ParticleSpecies
Is it possible to only make the function ParticleSpecies::computeMass a friend?
Member BaseParticle::setIndSpecies (unsigned int indSpecies)
TW do we have to update the species stored in the interactions here?
Member BaseParticle::setMass (const Mdouble mass)
I diasbled the MERCURY_DEPRECATED attribute until we actually fixed the deprecation issue. This will scare users away.
Member BaseParticle::setSpecies (const ParticleSpecies *species)
TW: this function should also check if the particle is the correct particle for the species type
Member BaseWall::setSpecies (const ParticleSpecies *species)
TW: this function should also check if the particle is the correct particle for the species type.
Member Chute::createBottom ()
Does the bottom we always has to be this particle? Maybe add a BaseParticle* argument, and add a default value with particle radius < 1e-12.
Member ChuteBottom::actionsBeforeTimeStep ()
Why does this method even exist? Can this be removed? (BvdH)
Member ChuteBottom::makeRoughBottom (Chute &chute)

the above should be replaced with sth like this (and setTimeMax(getTimeStep() * 1e4);), but this would break the selftest and old codes

Dinant is not a fan of this algorithm (i.e. popping back stuff while in iterator) Consider copying all (moved) valid particles directly to the chute handler instead, and apply the iterator in the for-loop initiation

after copying a particle handler, you have to set the species pointers to the species of the chute problem; a) do you need to set other things? b) this should probably be done in ParticleHandler::operator=() => YES INDEED, the operator=() should create a DEEP copy!

Member ChuteBottom::setupInitialConditions ()

The createBottom() function also creates some walls and boundaries, but at slightly different locations. In this version they are removed and reset, but this is (in my opinion (Dinant)) not the correct way.

Particles are created without insertion boundary... this reeks of double work (see also Dinant's todo in this same function (ChuteBottom::setupInitialConditions()). (BvdH)

Member ChuteWithHopper::addHopper ()
Why shift A by arbitrary number of 40, when isHopperCentred_ = True? NB: this is probably the same shift of 40 as happens in HopperInsertionBoundary::generateParticle(RNG) with the calculation of 'point A'. NB2: seems to be just generating a nice 'view' of the hopper (in the center of the viewer...?)
Member ChuteWithHopper::getTimeStepRatio ()
Consider generalising this method by implementing it in the MercuryBase class.
Author
BvdH NB: this method is used in ChuteWithHopper::setupInitialConditions().
Member ChuteWithHopper::setHopper (Mdouble ExitLength, Mdouble ExitHeight, Mdouble Angle, Mdouble Length, Mdouble Height)
: check whether HopperCornerHeight >=0, if not change hopperangle, line 105, I do not yet understand what the criteria is...
Member CircularPeriodicBoundary::checkBoundaryAfterParticleMoved (BaseParticle *P, ParticleHandler &pH)
{TW: Dinant, please confirm that i and oldI should be integer}
Class Coil

IFCD: Can someone look at the details of the documentation of class Coil? I can't make sense of them.

Coil is now fixed in Z-direction, centered around the Z-axis. Consider converting to more general parameters, with direction of choise and central axis of choice.

Member Coil::getDistanceAndNormal (const BaseParticle &P, Mdouble &distance, Vec3D &normal_return) const override
Make this function readable and explain the steps in the details.
Member Coil::getInteractionWith (BaseParticle *P, Mdouble timeStamp, InteractionHandler *interactionHandler)
{DK: What is the contact point for interactions with walls}
Page Directory Structure

TW What happened to the Template directory?

TW Anthony, please add information about your new output file here.

Member DPMBase::checkParticleForInteraction (const BaseParticle &P)
tw check against periodic copies (see ShearCell3DInitialConditions.cpp)
Member DPMBase::computeExternalForces (BaseParticle *PI)
take out computeWalls() from compute External Forces method.
Parameters
[in]CI
Member DPMBase::computeForcesDueToWalls (BaseParticle *PI)
TW: I think this torque has the wrong sign
Member DPMBase::setRotation (bool newRotFlag)
{these functions should also update the mixed species}
Member DPMBase::setupInitialConditions ()

I (Anthony) wants to change this to be an external function. This has a lot of advantages especially when using copy-constructors. This is a major change and will break other codes, so therefore has to be done carefully.

Member DPMBase::solve ()

Is it neccesarry to reset initial conditions here and in setTimeStepByParticle (i.e. should it be in constructor) Thomas: I agree, setTimeStepByParticle should be rewritten to work without calling setupInitialConditions

Is it neccesarry to reset initial conditions here and in setTimeStepByParticle (i.e. should it be in constructor)? Thomas: I agree, setTimeStepByParticle should be rewritten to work without calling setupInitialConditions

Member DPMBase::write (std::ostream &os, bool writeAllParticles=true) const

TW: random number seed is not stored

TW: xBalls arguments are not stored

Member File::open ()
tw: DEBUG_OUTPUT is currently only defined in DPMBase.h
Member File::write (std::ostream &os) const
TW: openMode_ is not saved, maybe it should not even be stored but set every time you open a file
Member FrictionInteraction::computeFrictionForce ()
TW: Why do we not use the corrected diameter here, as in the rolling case? And check if Stefan uses radius or diameter
Class FrictionSpecies
TW: should this class be renamed SlidingRollingTorsionFrictionSpecies?
Member helpers::computeCollisionTimeFromKAndDispAndEffectiveMass (Mdouble k, Mdouble disp, Mdouble mass)
This does not result in the same value as the given alternative.
Member HertzianViscoelasticInteraction::computeNormalForce ()

TWnow

check for superquadrics

Member HertzianViscoelasticInteraction::getElasticEnergy () const
TW This is not correct
Member HGrid::Initialize_inv_size ()
TW: Where is this function defined??
Class HGridOptimiser
Find out what this class does and document it.
Class HopperInsertionBoundary
(BvdH) Better graphical diagrams are needed for further clarification, as well as some property renaming.
Member HopperInsertionBoundary::generateParticle (RNG &random)

(BvdH) make a nice (InkScape) diagram with all useful properties in one image, and some angles explaining the definitions of AB and AC directions, the P->setPosition operation and the calculation of the Z-direction of the Vec3D A position.

Thomas, could you check if this bug is still valid? (BvdH)

Member InfiniteWall::getInteractionWith (BaseParticle *p, Mdouble timeStamp, InteractionHandler *interactionHandler)
{DK: What is the contact point for interactions with walls}
Member InfiniteWallWithHole::move_time (Mdouble dt)
TW: generalize the move function for all walls Allows the wall to be moved with time
Member InfiniteWallWithHole::set (Vec3D normal, Mdouble position, Mdouble holeRadius)
Since InfiniteWall:set is deprecated, should we deprecate this format as well (and similar formats in other walls)?
Author
weinhartt
Class InsertionBoundary
IFCD: Should operator= be implemented here and in the derived classes?
Member InsertionBoundary::checkBoundaryBeforeTimeStep (DPMBase *md)
rename to something like "insertUntilMaxFailed"?
Member InsertionBoundary::generateParticle (RNG &random)=0
(AT) think about implementation of this method here instead of in the children, since the checkBoundaryBeforeTimeStep (i.e., the actual insertion of particles) is also defined here. Current problem with this: boundary dimensions, which are needed for the particle placement, are now defined in the children, and depend heavily on its shape.
Member InteractionHandler::eraseOldInteractions (Mdouble lastTimeStep)
TW: this function has to be sped up with sth like this: erase(remove_if(begin(), end(), bind2nd(checkSpringTime(), lastTimeStep)), end());
Member InteractionHandler::readObject (std::istream &is)
TW: Change identifier in restart file from id to index; is there any reason the id should be kept after restarting, once this is done? (Note, the id is set to the old one in the particle handler because interactions store id, not indices; also note id's are slow
Member InteractionHandler::removeObjectKeepingPeriodics (unsigned const int id)
this function will create an error if the timeStamp is in the future! This should not happen (ever), but who knows.
Member IntersectionOfWalls::getInteractionWith (BaseParticle *p, Mdouble timeStamp, InteractionHandler *interactionHandler)
{DK: What is the contact point for interactions with walls}
Member IntersectionOfWalls::move (const Vec3D &move)
We should use the position_ and orientation_ of the IntersectionOfWalls; that way, IntersectionOfWalls can be moved with the standard BaseInteractable::move function, getting rid of an anomaly in the code and removing the virtual from the move function.
Author
weinhartt
Member IrreversibleAdhesiveInteraction::IrreversibleAdhesiveInteraction (const IrreversibleAdhesiveInteraction &p)
tw check if the parameters are valid when inserting the species into the handler
Class LeesEdwardsBoundary

Add link to paper by Lees-Edwards in the documentation of this class.

Is implemented for 2D only now. Needs extension to 3D.

Member LinearPlasticViscoelasticInteraction::computeLinearPlasticViscoelasticForce ()
TWnow this has to be corrected; I think the dissipation force is applied in the wrong direction
Member LinearPlasticViscoelasticInteraction::getElasticEnergy () const
TW this is not correct; we should count the return energy
Member LiquidBridgeWilletInteraction::getElasticEnergy () const
TW
Member MaserBoundary::checkBoundaryAfterParticleMoved (BaseParticle *p, ParticleHandler &pH UNUSED)

Apparently, somewhere in the ages past, at some time, there has existed a piece of code which prevents the particles crossing the periodic boundary on the left side from reappearing on the right. This was taken out somewhere between the dark ages an the current one (feb. 2015) and should be put back in. Only causes errors very rarely, and not in the compiler but rather in the actual physics going on (So its not detected by the MaserSelfTest). The current arrangement mainly causes problems with particles which oscillate on the boundary, continuously crossing from left to right and back. A visual consideration of this problem can be found in Documentation/Images/Maser_unperiodic_behaviour.jpg, which, granted, is appalling in its own right, but has yet to suffice in awaitance of a better (i.e. clearer) drawing. Therefore:

Create a new diagram explaining the problems with the previous (NOW: CURRENT!) implementation, and the exact differences between the two. I.e., an improved version of Documentation/Images/Maser_unperiodic_behaviour.jpg. (BvdH)

Member MaserBoundary::createPeriodicParticles (BaseParticle *p, ParticleHandler &pH)
The code has not implemented the actual outflow of 'normal' particles from the right boundary wall. I.e., the maser now is 'simply' a normal Periodic Boundary, with a lot of potential ;). I think the 'original author' planned to implement the outflow below, which is still left to be done. (BvdH) NB: a better place would be in the MaserBoundary::shiftPosition() or MaserBoundary::checkBoundaryAfterParticleMoved() method, which are called when the particles actually cross either of the boundary walls.
Member MaserBoundary::shiftPosition (BaseParticle *p)
Reconsider the way in which the shifting of particles is done. Now, the procedure is as follows: > PARTICLE's distance to either of the two walls is gotten by MaserBoundary::getDistance > Which of the two walls the particle is closest to, is saved in the BOUNDARY's boolean data member closestToLeftBoundary_ > PARTICLE's position is then shifted based on the BOUNDARY's closestToLeftBoundary_ data member and shift vector What might go wrong, is that it is allowed now to do a shift operation on the particle without being forced to first have the closestToLeftBoundary_ boolean set based on the same particle. Suggestion: get rid of the closestToLeftBoundary_ data member all together (it is a property of the particle after all, rather than one of the boundary), and implement the obtaining of which boundary to shift relatively to directly into the shift function. (NB: The PeriodicBoundary class contains the same TODO).
Class MercuryBase
Discuss if we want to remove Mercury2D and Mercury3D and template MercuryBase as the interface for the user.
Member MercuryBase::checkParticleForInteraction (const BaseParticle &P) override
IFCD: I think it might be better if it returns true if there is an interaction.
Member MercuryBase::hGridActionsBeforeTimeStep () override

IFCD Look up if stepsBeforeUpdate is actually used.

TW: I believe the following two steps should be in hGridRebuild

Member MercuryBase::setHGridCellOverSizeRatio (Mdouble cellOverSizeRatio)
IFCD: I changed the if unequal to if equal, can someone check this is correct?
Member MercuryTimeStep< NDIMS >::dataFile_
Chris, please check if this parameter is needed; it causes a warning with [-Wunused-private-field]
Author
weinhartt
Member ParticleHandler::largestParticle_
TW: note that checkExtrema gets called if a particle gets created and its Species and Radius gets set, even if it's not yet included in the particleHandler! This is necessary to check a not included particle for overlaps before inserting it into the handler. Not sure if this is a sensible structure; to be discussed.
Member ParticleHandler::readObject (std::istream &is)

make sure setting the id doesn't break the id setter :)

{Remove for final version}

Member ParticleSpecies::getMassFromRadius (const Mdouble radius)
TW: should getMassFromRadius be removed? IFCD: it is used in at least one driver (AxisymmetricHopper).
Member ParticleSpecies::setDensity (Mdouble density)
recalculate masses when setting dim_particle or rho
Member PeriodicBoundary::shiftPosition (BaseParticle *p)
Reconsider the way in which the shifting of particles is done. Now, the procedure is as follows: > PARTICLE's distance to either of the two walls is gotten by PeriodicBoundary::getDistance > Which of the two walls the particle is closest to, is saved in the BOUNDARY's boolean data member closestToLeftBoundary_ > PARTICLE's position is then shifted based on the BOUNDARY's closestToLeftBoundary_ data member and shift vector What might go wrong, is that it is allowed now to do a shift operation on the particle without being forced to first have the closestToLeftBoundary_ boolean set based on the same particle. Suggestion: get rid of the closestToLeftBoundary_ data member all together (it is a property of the particle after all, rather than one of the boundary), and implement the obtaining of which boundary to shift relatively to directly into the shift function.
Member PeriodicBoundary::shiftPositions (Vec3D &postition1, Vec3D &postion2)
(AT) see toDo of PeriodicBoundary::shiftPosition().
Class PossibleContact
Change the names so that they follow the code guidelines.
Class PossibleContactList

Look at the memory management of PossibleContactList. Maybe a destructor that takes out all remaining PossibleContact? Or is there a Handler that calls remove_ParticlePosibleContacts for all particles?

Restart-tests are not working with CONTACT_LIST_HGRID turned on, so either finish the ContactList-related code, or get rid of it. If we keep it, clean up the code, in particular the naming-convention.

Member Quarternion::integrate (const Vec3D &omega, double timeStep)
Are we sure this works? *this = deltaQ * *this
Author
weinhartt
Member ReversibleAdhesiveInteraction::getElasticEnergy () const
TW
Returns
Mdouble
Class RNG
(AT) implement new C++-standard RNG instead of this one (Kudos on the hard work done here though ;). NB: maybe something for Mercury 2?
Member RNG::RNG ()

{Thomas: This code does sth. when min>max; I would prefer to throw an error.}

{the random seed should be stored in restart}

Member RoughBottomType

consider converting to an enum class.

consider changing to just 'bottomType' and add 'FLAT' (or something similar) as an option so that from ALL bottom types can be chosen with just ONE enumerator IFCD: I did add FLAT, but since there are multiple users using RoughBottomType, it might be a bad idea to change the interface with BottomType. Please also check if I have forgotten places to add "FLAT" to make this a complete interface.

Class Screw
IFCD: Can these details about class Screw be made more clear? I don't understand them.
Member Screw::getDistanceAndNormal (const BaseParticle &P, Mdouble &distance, Vec3D &normal_return) const final
Make this function readable and explain the steps in the details.
Member Screw::getInteractionWith (BaseParticle *p, Mdouble timeStamp, InteractionHandler *interactionHandler) final
{DK: What is the contact point for interactions with walls}
Member SlidingFrictionInteraction::getTangentialOverlap () const
TWnow this should be positive
Member SpeciesHandler::addObject (ParticleSpecies *const S)
TW don't put logger messages that only make sense for one application!
Member SpeciesHandler::getMixedObject (const unsigned int id1, const unsigned int id2)
This function should probably be made private. The user should use the function SpeciesHandler::getMixedObject(const U* S, const U* T), which deals with pointers.
Member SpeciesHandler::readObject (std::istream &is)
TW why does deleting these objects create a segmentation fault How do you create the segmentation fault?
Author
weinhartt
IFCD how does the numbering of mixedSpecies_ work? the numbering of mixed species is 01, 02, 12, 03, 13, 23, 04, 14, 24, 34, i.e. if you add the n-th ParticleSpecies, then you have to add n-1 MixedSpecies. So here I remove the last n-1 MixedSpecies and add n-1 new ones.
Author
weinhartt
Member StatisticsPoint< T >::CG_gradient (const Vec3D &P, const Mdouble phi)
{Only implemented for Gaussian}
Member StatisticsPoint< T >::CG_integral_gradient (Vec3D &P1, Vec3D &P2, Vec3D &P1_P2_normal, Mdouble P1_P2_distance)
{Only implemented for Gaussian and statavg Z}
Member StatisticsPoint< T >::CollisionalHeatFlux
{Heat flux calculations have not been checked, only implemented}
Member StatisticsPoint< T >::Dissipation
{Dissipation calculations have not been checked, only implemented}
Member StatisticsPoint< T >::Potential
{Potential calculations have not been checked, only implemented; fstat file does not include the torsional and rolling spring and hence cannot account for their potential}
Member StatisticsVector< T >::periodicWalls
{Thomas: the case periodicWalls=true seems to mess up some statistics. Needs to be checked or removed}
Member StatisticsVector< T >::rmin
Thomas: maybe this fixed condition should be replaced by a condition function, bool include_statistics_if()
Member to_string_padded (unsigned int value)
TW: I am not able to define the operator >> for enum class type (the implementation works fine for the old enum)
Class Vec3D
Need to generalize this to n-dimensional vectors of any type