Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Gurson material model #7

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Adding Gurson material model #7

wants to merge 1 commit into from

Conversation

TeroFrondelius
Copy link
Member

No description provided.

src/UMAT.jl Outdated Show resolved Hide resolved
@ahojukka5
Copy link
Member

I think we should use Int instead of Int64. This is not a big issue but with 32-bit machines, Int will be Int32 and with 64-bit machines, it will be Int64, automatically. So this way the code will be compatible with all kinds of machines.

julia> Int
Int64

src/UMAT.jl Outdated

"""
Variables updated by UMAT routine.
"""
@with_kw struct UmatVariableState <: AbstractMaterialState
NTENS :: Int64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here, instead of Int64, Int is a better choice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I will change all. How about Float64, is that ok?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good question. I think that the use of Float64 is ok. I'm not sure about why this Int32/Int64 is a problem with integers but not with floats. In principle, you could use template to have two structs, one for Float32 and another for Float64, but I have not seen these kinds of practices anywhere so far. So I think that Int and Float64 is the right way to go.

https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this is only when defining structs. When defining new functions, the use of abstract types is not hitting performance at all.

function foo(x::AbstractFloat, y::Integer)
    # do something with `x` and `y`
end

is perfectly fine.

@TeroFrondelius
Copy link
Member Author

@ahojukka5 any ideas, where my problem is? When I run the test UMAT first time, I usually get this error:

** On entry to DGESV   parameter number  4 had an illegal value

But it will go away if I run test UMAT a few times and the test passes. In Travis, Linux build, it seems to fail systematically. I think I have a problem with setting the model correctly.

@ahojukka5
Copy link
Member

It has something to do with matrix dimensions?

@TeroFrondelius
Copy link
Member Author

It has something to do with matrix dimensions?

I hope #11 will fix the problem. See issue #10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants