Scalar constants defined in model should be used in Julia service

[epatters]

Currently a single constant,diffusivity, is hard-coded in the AlgJulia service.

Follow up issue to #283.

[epatters]

Actually, the situation seems to be more complicated. An item diffusivity is included in the morphism mapping but it doesn't seem to be used anywhere else. I guess it should be removed?

Instead, there is code here pertaining to scalars but I don't understand the comment or the logic. There is no reliable connection between scalar multiplication operations and anonymous objects; scalar operations can be applied to named or anonymous objects. The scalar multiplication morphisms are the ones with this morphism type. So I think something needs to be fixed here.

[quffaro]

The comment indeed is incorrect and should be removed. I think it comes from a brief interval in time when scalar multiplication and anonymous functions were more tightly linked.

The reason for the :diffusivity symbol in the mapping statement is so the corresponding entry in the model (this example) would map to an operation/function in the sys_generate function Julia-side.

It seems like this code is working accidentally. We don't distinguish by "morType" in the theory-building, we just check that there is a morphism which is linked to a corresponding id in the scalars JSON field. The resulting anonymous function is thrown into the anons dictionary and handled in the sys_generate function.

Is the correct implementation to have the HomType method for add_to_theory! dispatch on the morType as well? It seems we'd still need to push curried op2 functions onto anons until we have higher arity operations implemented.

[epatters]

Is the correct implementation to have the HomType method for add_to_theory! dispatch on the morType as well? It seems we'd still need to push curried op2 functions onto anons until we have higher arity operations implemented.

Yes, that sounds like a good approach to me. Right now, there will be two cases to handle in the dispatch, corresponding to the two morphism types in the double theory bound in theories.tsx. In the future, we might have other morphism types, I don't know. So dispatch seems like a good flexible mechanism to handle this.

[quffaro]

This feature was completed in this commit. A @match statement was added to the morphism method for add_to_model! to check if the morType was Nonscalar. If it was, the name of the cell would be checked against a look-up table, but otherwise the name would be converted to a Symbol.

I move to close this issue.

[epatters]

Thanks Matt!