PDE Toolbox - function handle specification

I am setting up a system of equations using the PDE Toolbox, but I seem to be running into some issues with this. My current formulation uses function handles for some of the coefficients in the form f(location,state); however, when I attempt to set the model coefficients to these values, an error is thrown within the coefficient validation function (specifically, the portion where a check is made that the function is of the form f(p,t,u,time)).

I am confused why this form is needed as the documentation specifies that the function handle should be of the first form (having location and state passed as input arguments). Is this additional check intended to occur in all cases, or am I potentially misunderstanding the documentation here?

[Walter Roberson]

I think it would help if we had your code.

[Steven Lord]

The full and exact text of the error message could be useful in diagnosing the root cause of the error as well.

[Thomas]

@Steven Lord: There seems to be an issue in the way that function handle coefficients are validated. The coefficients are checked using a "default" state consisting of 1 element each in the u, ux, uy, and uz fields; however, if the function handle references indices greater than 1 for either rows or columns (as would be valid if the actual state matrix being processed had those dimensions), an error is thrown during the check since those indices are invalid for the "default" state used.

I am no longer encountering my initial error; however, the new error is thrown on line 498 of CoefficientAssignment.m. As stated above, when the function handles having row/column indices greater than 1 are used with the "default" state as input, the function throws an error since it attempts to reference a nonexistent index. I would think that this should be changed so that the check uses the actual state dimensions for the PDE model and not the default values within this file.

[Walter Roberson]

Is that similar to https://www.mathworks.com/matlabcentral/answers/1949718-function-handle-as-boundary-condition ?

[Thomas]

@Walter Roberson There is some overlap, but I have already modified my functions so that they comply with the specified format (being of the form f(location,state)). The issue is that the validation checks for these functions assume a state matrix with one element (i.e., state.u is a 1x1 array).

Let's say our actual state matrix has four equations and three points at which the solution is being evaluated. Then our function handles can legitimately reference row indices from 1-4 and column indices from 1-3. However, since the "default" state used to validate these handles only has a 1x1 matrix for each field, an example function that references state(4,:) will fail execution during this check since the row reference (4) is greater than the number of rows of the input state value (1).

[Walter Roberson]

Surely your function handles could be written to test the size of the array?

[Thomas]

@Walter Roberson Yes, but I would argue that having to do this indicates suboptimal design of the toolbox functions. I would have expected the parameters of the state matrix being used (size) to be passed to the validation function so that the handles are validated against the same type of input that they would be receiving in the actual PDE model.

@Steven Lord Is this something that could potentially be changed in an update to this toolbox?

[Torsten]

The coefficient functions are designed to compute their return values based on the values of x,y and u in one point for which they are called. Why is it necessary in your case to reference more than one point per call ? What do you want to specify by the coefficient function ?

[Thomas]

My understanding based on the documentation is that the function handle should return a NxNr matrix where N is the number of equations being solved simultaneously and Nr is the number of location points.

I'll give as an example the sample code in "f Coefficient for specifyCoefficients" (https://www.mathworks.com/help/pde/ug/f-coefficient-for-specifycoefficients.html). The fcoeffunction implementation at the bottom of this page will fail validation by the functions in CoefficientAssignment since it references the third row of state.u and state.uy; as with my functions, since the sample state used for validation only has 1 row and 1 column, referencing a row greater than 1 will result in an error.

[Torsten]

So in your PDE model, the number of partial differential equations is also 3 (as assumed in the fcoeffunction implementation from https://www.mathworks.com/help/pde/ug/f-coefficient-for-specifycoefficients.html ) and you get an error when you try to reference state.u(2,:), state.u(3,:), state.ux(2,:), state.ux(3,:), state.uy(2,:) or state.uy(3,:) ?

[Thomas]

I have more than three equations in my model, but the fundamental issue remains - the default state/location arguments for function handle validation only have 1x1 arrays for each field. Therefore, a function handle that references rows/columns greater than 1 for fields of either "state" or "location" (fcoeffunction being an example of this) will fail execution when called within the validation function.

[Torsten]

If this were true, it would be a bug. If you can't share an example file that reproduces this behaviour here in the forum, you should report it to Mathworks support and ask for help there.

Maybe you define the number of equations used in your model after you define the coefficient functions ?

[Thomas]

@Torsten @Steven Lord I was able to resolve this issue by explicitly setting the PDESystemSize property for the model prior to calling specifyCoefficients with my function handles (this property is used to appropriately size the sample state matrices for function validation). It appears that this property is not set automatically and must be set manually by the user when initializing a model; however, this is not identified in the documentation as a necessary step when using function handles like the ones I've described (and the ones that are provided in the examples from the documentation).