Handling default values for columns when assigning tabular cards with dataframes

[heyangzhang]

extra kwargs.get in duplicate card group

[koubaa]

Currently, defaults and values provided via kwargs are ignored in duplicate card groups.

This can be resolved in one of two ways:

1. remove default value from the fields in DuplicateCardGroup
2. handle the default values in DuplicateCardGroup

The behavior right now looks like the following. A script like this:

import pandas as pd
from ansys.dyna.keywords import *
from ansys.dyna.keywords.card import Card, Field
from ansys.dyna.keywords.duplicate_card_group import DuplicateCardGroup
group = DuplicateCardGroup(
    [
        Card(
            [
                Field("a1", int, 0, 8),
                Field("a2", int, 8, 8),
                Field("a3", int, 16, 8),
            ],
        ),
        Card(
            [
                Field("b1", float, 0, 16, 0.0),
                Field("b2", float, 16, 16, 0.1),
                Field("b3", float, 32, 16, 0.2),
            ],
        ),
    ],
    None
)
data = pd.DataFrame({"a1":[1,2,3]})
group.table=data

will currently produce a table like this:

   a1    a2    a3  b1  b2  b3
0   1  <NA>  <NA> NaN NaN NaN
1   2  <NA>  <NA> NaN NaN NaN
2   3  <NA>  <NA> NaN NaN NaN

if the defaults are handled, it would have done this:

   a1    a2    a3   b1   b2   b3
0   1  <NA>  <NA>  0.0  0.1  0.2
1   2  <NA>  <NA>  0.0  0.1  0.2
2   3  <NA>  <NA>  0.0  0.1  0.2

@ansmhoeij what do you think makes more sense?

[mhoeijm]

This is a difficult one and my impression is that whether partially providing the data for a duplicate card group makes sense would depend on the actual keyword that is involved. Moreover, this would depend on whether the defaults make sense when you just change one of the other data fields.

Perhaps it is better to be explicit (either you provide everything or nothing) than sort of implicit?

Could you list a few keywords would be affected by this?

[koubaa]

@ansmhoeij basically any keyword that uses a data frame would be affected - so long as one of the columns has a default. right now, we keep the default column empty (which will cause the DYNA solver to use its default). I think I also lean towards making it explicit, since dynalib will be simpler because of it. But it is in a sense some information loss because the python classes no longer document the defaults.