SysMLv1: CAUTION: Only a Signal can be used for a SendSignalAction or MessageEvent trigger of an AcceptEventAction, not a Block or ValueType, even if they are valid types for a SysML FlowProperty! But you can "wrap" a Block or ValueType in a Signal.
SysMLv1: Cameo Simulation Toolkit: GOTCHA: Do not use Associations with Signal attributes, they will become null when fed as argument values for Parameters of 'effect' Behaviors of Transitions
fUML1.4: Cameo Simulation Toolkit: LIMITATION: CreateObjectAction is not allowed to instantiate a UML DataType or a SysMLValueType, only a Class as the CreateObjectAction::classifier! WORKAROUND: Use a ValueSpecificationAction instead with an instance.
Webel: Psy/MPsy: Psychrometrics for Mathematica: '$HC' in a function name indicates pure sensible heating or cooling (with no change in water vapour content). Such functions may also be used in the pure sensible portion of a 2-step treatment.
SysMLv1.x: Limitation: The 'body' (maths formula) of an OpaqueBehavior can't be synchronised (shared) with the 'constraint' of a ConstraintBlock (directly in the SysML model). Can lead to a WET (not DRY) model and breaks Single Source of Truth!
SysML: Cameo Systems Modeler: A ValueType that does not extend Real might not always simulate correctly when used to type a constraint parameter of a ConstraintBlock (in a SysML Parametric Diagram) or to type a parameter (in a SysML Activity Diagram)!
Webel: SysML4Mathematica: SysML Parametric Diagrams are not well suited to modelling calculations with Blocks for MTools classes, or for modelling complex logic flow of Mathematica functions. Prefer SysML Activity Diagrams for those modelling cases.
SysML/UML: MagicDraw/Cameo: GOTCHA: Connecting a typed OutputPin to an untyped (UNSPECIFIED) InputPin with an ObjectFlow changes the type of the InputPin
Webel: SysML4Mathematica: Convention: A '$E' in a function name indicates that all parameters (arguments and return) are Mathematica '_' expressions. However, when representing such functions as Activities they may end up getting strongly typed in tools!
Webel: SysML4Mathematica: Cameo Systems Modeler: Can perform calculations with a custom Quantity ValueType (for Mathematica) directly, but DOES NOT perform units-aware algebra (no automatic conversions)
Webel: WISHLIST: MagicDraw/Cameo: UML/SysML: Ability to freeze the Feature lines shown on symbols under Edit Compartments so that the diagram does not "break" when new Features are added elsewhere (reduce graphical coupling)
CoolProp: Mathematica: Mac: HOWTO get CoolProp for Mathematica running on Apple M1 Max and Mathematica13
Mathematica: Use of UnitConvert (or even just multiplication or division by a unit Quantity) MASSIVELY slows the calculations down!
CoolProp: HOWTO reproduce a pressure vs specific enthalpy chart in Mathematica. Example: R32 refrigerant.
Mathematica: CoolProp wrapper binaries don't seem to be maintained past CoolProp 5.1.1 (and the PhaseSI and 2-args Props1SI functions do not work)
Mathematica: MTools: Argument Pattern strong type matching does not intrinsically respect inheritance (makes implementing design-by-contract and some Design Patterns less convenient). But you can use PatternTests with Webel MAll extensions.
Mathematica: Wolfram Workbench: Basic variable name refactoring is not supported. (Or just use the IntelliJ IDEA Plugin for Mathematica, which does variable and function renaming well.)
Mathematica: How mimic pattern matching of arguments for pseudo "Boolean" (including providing a default)?
Wolfram Workbench for Mathematica: Limitation: Using more than one '$' sign within function names blocks navigation on function usages.
Webel: Mathematica: WISHLIST: Support for EXTRACTABLE structured documentation for individual arguments of functions RIGHT IN/NEAR THE CODE. Yes it is needed, really it is. (And ::usage support for "methods" would be nice too.)
MagicDraw/Cameo: 19SP3: Although a 0..* or 1..* Property can carry more than one value, the interface only permits assignment of a single Property::defaultValue through the specification dialog
Webel Parsing Analysis: MagicDraw/Cameo: SysML1.6+: ElementGroup-based Snippets do not list in the compartment of Package/Model symbols because ElementGroup is based on the UML Comment, which does not list in Package/Model symbols.
The SysML1.6 derived /tracedTo is only available on AbstractRequirement (but in MagicDraw/Cameo you can use derived relationships to achieve the same thing on other kinds of NamedElement).
The UML «Trace» and SysML Trace can't be applied to a Slot as target (because Slot is just an Element, not a NamedElement).
SysPhS vs Modelica: If you redeclare a PhSConstant (Modelica parameter) as a PhSVariable (Modelica variable) Modelica still treats it as a 'parameter'. You can end up with an unbalanced system with one equation too many!
SysPhS-1.1: Does not support Modelica's 'initial equation'. WORKAROUND: One can often achieve the same by directly setting a default on a variable and/or by using additional variables/parameters with 'start' and additional equations.
Cameo Simulation Toolkit DOES NOT leverage a Reception on a Class/Block at all! Use an AcceptEventAction with a SignalEvent trigger or an 'effect' on a Transition instead. There is a formal fUML restriction that a Reception should not have a method.
