Perhaps tweak the way loads are defined to specific dimension

[KristofferC]

Right now, a load is applied to a set of dimensions by giving a string with the dimension after the name of the load, for example

update!(support_elements, "displacement load 1", 0.0)
update!(support_elements, "displacement load 2", 0.0)

means we apply a load in dimension 1 and 2.

In the problem this is then checked using something like

            if haskey(element, "displacement load")
                T = element("displacement load", ip, time)
                f_ext += w*vec(T*N)
            end

            for i=1:dim
                if haskey(element, "displacement load $i")
                    b = element("displacement load $i", ip, time)
                    f_ext[i:dim:end] += w*vec(b*N)
                end
            end

I would argue that it would be better to specify the dimensions in some type of vector instead of in a string, for example:

update!(support_elements, "displacement load", 1, 1.0) # dim 1
update!(support_elements, "displacement load", 2:3, 1.0) # dim 2, 3
update!(support_elements, "displacement load", [1, 3], 1.0) # dim 1, 3
update!(support_elements, "displacement load", 1.0) # dim 1, 2 ,(3) all dimension by default

and the code using the load would get the dimensions it is applied to and the value as

b, dim = element("displacement load", ip, time)

This would require fewer dictionary looksups and be a bit more "Julian".

[TeroFrondelius]

I like the idea.

[ahojukka5]

I also like the idea. There is a couple of practical things needs to be solved.

The first problem is that the field is created on the fly at the first time when something is updated to that field. So we are not aware of the internal structure before calling update!. We should initialize field beforehand to know its dimension and data type. On the other hand, it's not a bad idea of having e.g. create_field! which is called at the first time. Explicit is better than implicit and now we are implicitly creating new fields given new names. We also need a way to update tensor fields using the same logic.

Another problem I see is that if we update values for e.g. values (1, 3) like in the example, what is the value of the field for the second component? I agree we should have better ways to control multidimensional fields, but it sounds a bit that we need to make those implementations to fields.jl and define new types of fields.

[ahojukka5]

Maybe element("displacement load", ip, time) could return something like (1.0, NaN, 2.0), 3 in the case where not all components of a field are not defined.