Gauss-Kronrod Trapezoidal Rule, integer input error?
issueid=720 06-29-2015 07:44 AM
Gauss-Kronrod Trapezoidal Rule, integer input error?
Gauss-Kronrod Trapezoidal Rule, integer input error?

I believe there is a minor bug in the implementation of the parameters for the "Gauss-Kronrod Trapezoidal Rule" (I did not check others). I believe it may force interpretation of the input as (unsighned) integer values leading to errors if the form is different. Both of the following inputs should represent nph=7 and nth=31:

<scheme type="fibers-3d-gkt">

<scheme type="fibers-3d-gkt">

The former approach led to a model that terminated normally the latter was unable to terminate normally (but did start somehow but not sure with what numbers).

If I change to a two digit input for nph e.g. 11 i.e.
<scheme type="fibers-3d-gkt">

I now get the error message:
Failed initializing material 1 (name="mat_1"):
ERROR: nph must be 7, 11, 15, 19, 23, or 27.

Issue Details
Issue Number 720
Project FEBio
Category Unknown
Status Not a Bug
Priority Unknown
Affected Version Unknown
Fixed Version (none)
Users able to reproduce bug 0
Users unable to reproduce bug 0
Assigned Users (none)
Tags (none)

06-30-2015 08:19 AM
Hi Kevin,

The behavior you describe is the expected behavior for integer input. Providing a floating point number as an input (even if it is in fact an integer) will produce incorrect outcomes, as you noted.

Are you requesting that we allow specifying integers as floating point numbers? The variables associated with nph and nth are integers in the code. To address your concern, for every integer input in FEBio, we would have to create a floating point variable then convert it (by rounding) to an integer. That would most likely lead to more confusion if users overlook the fact that these parameters must be integers.

If I misunderstood this issue please let me know.



06-30-2015 08:39 AM
Yes that is exactly the point I mean.

Perhaps I am the only one that would have this problem because I create the model using GIBBON and MATLAB and my code at present treats this numerical input as floating points. The subroutine code is shared with code for other attributes that do need to be floating points. To treat this I could therefore add some kind of if statement to check if the attribute name is nph or nph and to convert to integer there. I can understand your objections so I'll make the changes to my code.

Thanks for checking this,


+ Reply