Constructing 'constrained' objects with empty constraints

[JacquesCarette]

Currently it is possible to build something (say via constrained') that is "constrained" but in fact has an empty list of constraints (there are examples in Game Physics). This is a double bug:

1. in the infrastructure, which allows this
2. in usage, which uses this.

@danscime can you please augment this Issue with a list of all of the uses of this buggy feature? We need to know the scale of the problem before we 'just fix it'. Then this can be assigned to the appropriate people.

[danscime]

Searched project for usages of:
uq, uqc, uqcND, cvc, constrained', cuc, cuc', cuc'', constrainedNRV', cnstrw, cnstrw', uvc

Found empty list usages:

Using constrained':

GamePhysics Unitals:
  gravAccelCons
  posCons
  veloCons
  orientCons
  angVeloCons
  forceCons
  torqueCons

Using cuc':

SSP Unitals:
  coords

Using uqc:

SSP Unitals:
  slopeDist
  slopeHght
  waterDist
  waterHght
  xMaxExtSlip
  xMaxEtrSlip
  xMinExtSlip
  xMinEtrSlip
  yMaxSlip
  yMinSlip

[JacquesCarette]

Each one of these look like they need a 'domain expert' to look at it, to decide whether there should be a constraint [and add it], or there shouldn't be, and a different constructor should be used. @smiths can you do that task assignment please? Then we should make it illegal to use the constructors that expect a constraint to get none.

[smiths]

@JacquesCarette, are we just taking about physical constraints? That is constraints for things that physically cannot happen? We distinguish these from software constraints. The software constraints are not imposed by the "universe," but by the context of the specific problem. For instance, x and y coordinates can take on any value between -inf and inf. They are not constrained.
However, for a specific problem, there may be bounds. We don't really know this until we look at the specific problem. This happens for the solar water heating tank for its dimensions. Physics requires that the dimensions be greater than zero, but engineering common sense puts other limits, like Lmin <= L <= Lmax.

[oluowoj]

Searched project for usages of:
uq, uqc, uqcND, cvc, constrained', cuc, cuc', cuc'', constrainedNRV', cnstrw, cnstrw', uvc
Found empty list usages:
Using constrained':
GamePhysics Unitals:
gravAccelCons
posCons
veloCons
orientCons
angVeloCons
forceCons
torqueCons

Using cuc':
SSP Unitals:
coords

Using uqc:
SSP Unitals:
slopeDist
slopeHght
waterDist
waterHght
xMaxExtSlip
xMaxEtrSlip
xMinExtSlip
xMinEtrSlip
yMaxSlip
yMinSlip

I was just looking at the physics example yesterday and tried to see if there is a constructor that can be used specifically for empty constraints instead of using constrained' for those ones, I have not found, let me know if you find one.

[JacquesCarette]

@smiths you are over-complicating things: my issue is much simpler. We are using a constructor for "constrained" things when in fact we give no constraints. This feels like a bug.

@oluowoj if you're trying to build something with empty constraints, then you ought to be building something "lower down" in the hierarchy of quantities. There's a dependency graph of the classes somewhere, that should be your guide.

[smiths]

@JacquesCarette what are you looking for from me? Yes, we shouldn't constrain things that do not have constraints.

[JacquesCarette]

@smiths : I want someone knowledgeable to review each use of an empty constraint to figure out whether that is correct (and thus a different constructor should be used), or there ought to be a constraint but it's not there. I would like you to do the assignment of that review to the 'right' people in the team, given the domain of each use, as given in @danscime 's list.

[smiths]

@JacquesCarette based on your response, I'll assume that you are only interested in the physical constraints. The software constraints would be problem specific, but physics constraints will always apply. I'll go through the list from @danscime and identify any missing physical constraints. My guess is that most of the items in his list do not have physical constraints, except maybe for some that should be constrained to be positive. @danscime, to save me some time, can you repeat your list again, but this time include the definition of each object?

[danscime]

I think some more have been added and removed since I made the list, so I will include updated ones here.

Using constrained':

GamePhysics Unitals:
gravAccelCons - Gravitational constant (aside: not acceleration, should maybe be renamed)
posCons - General Position (given a typical value, but not sure how it is used.)
veloCons - General Velocity (given a typical value, but not sure how it is used.)
angVeloCons - Angular velocity
forceCons- General Force (given a typical value, but not sure how it is used.)
torqueCons - Torque
posOutCons - General Position output
veloOutCons - General Veolcity output
angVeloOutCons - General Angular Velocity output

Using cuc':

SSP Unitals:
coords - General x and y coordinate pair (not sure how it is used.)

Using uqc:

SSP Unitals:
slopeDist - x-coordinates of points on the soil slope
slopeHght - y-coordinates of points on the soil slope
waterDist - x-positions of the water table
waterHght - heights of the water table
xMaxExtSlip - maximum potential x-coordinate for the exit point of a slip surface
xMaxEtrSlip - maximum potential x-coordinate for the entry point of a slip surface
xMinExtSlip - minimum potential x-coordinate for the exit point of a slip surface
xMinEtrSlip - minimum potential x-coordinate for the entry point of a slip surface
yMaxSlip - maximum potential y-coordinate of a point on a slip surface
yMinSlip - minimum potential y-coordinate of a point on a slip surface

[bmaclach]

I can speak to the ones from SSP since I worked with those. All of the ones under the "Using uqc" heading should indeed have constraints, but the constraints were too complicated to capture given what we currently have in Drasil. The constraints were instead written in words in the "Notes" section of IM:crtSlipId.

coords is used a couple times throughout the document to generically refer to coordinates without having to specify if they are slope coordinates, water table coordinates, slip surface coordinates, or critical slip surface coordinates. It's probably a hack and should be replaced with the specific types of coordinates wherever used.

[JacquesCarette]

@bmaclach we should make issues for each of those 'too complicated to capture'. They should be eventually fixed. But in the meantime, we should fix things to use the right constructor: I really want to upgrade the 'constrained' constructors to throw an error when there are none given!

[bmaclach]

Issues #1795, #1796, #1797, #1798, #1799, #1800 created. #453 for monotonicity constraints already existed.

[smiths]

Thank you @danscime. This information is very helpful. I'll edit in my thoughts below.

I think some more have been added and removed since I made the list, so I will include updated ones here.

Using constrained':

GamePhysics Unitals:
gravAccelCons - Gravitational constant (aside: not acceleration, should maybe be renamed)

Yes, this should be renamed. (@danscime, can you please create an issue for this.) If I remember correctly, this is the gravitational constant from Newton. It definitely does not have a constraint. It is a constant. I guess it has a constraint that it can only take on one value, but if we have the notion of constants, then we wouldn't express this with a constraint.

posCons - General Position (given a typical value, but not sure how it is used.)

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics
point of view.

veloCons - General Velocity (given a typical value, but not sure how it is used.)

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

angVeloCons - Angular velocity

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

forceCons- General Force (given a typical value, but not sure how it is used.)

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

torqueCons - Torque

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

posOutCons - General Position output

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

veloOutCons - General Velocity output

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

angVeloOutCons - General Angular Velocity output

I cannot think of any constraints for this. Any value (real number) should be valid, from a physics point of view.

Using cuc':

SSP Unitals:
coords - General x and y coordinate pair (not sure how it is used.)

@bmaclach is right that this should probably be changed to the specific coords that are being referenced. In the mean time, we cannot reasonably constrain this variable.

Using uqc:

SSP Unitals:
slopeDist - x-coordinates of points on the soil slope
slopeHght - y-coordinates of points on the soil slope
waterDist - x-positions of the water table
waterHght - heights of the water table
xMaxExtSlip - maximum potential x-coordinate for the exit point of a slip surface
xMaxEtrSlip - maximum potential x-coordinate for the entry point of a slip surface
xMinExtSlip - minimum potential x-coordinate for the exit point of a slip surface
xMinEtrSlip - minimum potential x-coordinate for the entry point of a slip surface
yMaxSlip - maximum potential y-coordinate of a point on a slip surface
yMinSlip - minimum potential y-coordinate of a point on a slip surface

@bmaclach has discussed these in the issues below.