Chenard results contradict

[Ingrid Schockaert]

Hi all,

Using the Chenard algoritm in LiamII, I came accross the following problem.

I used two different codes:

MODEL1:

entities:   
    Household:

         processes:

            select_int_emigrants: 
                - migrant_pool: FALSE
                - num_persons: persons.count()
                - int_migration_targets: load('emigr_target.csv', type=int)
                - is_candidate: uniform () >0.5 
                - migrant_pool: align_abs(num_persons, int_migration_targets, filter=is_candidate, link=persons)
                - show("migrant pool", sum(migrant_pool * num_persons))
 
            

where 'emigr_target.csv' looks like:

res_id,age,gender,          ###municipalit,age,gender

,,True,False

11001,0,4,5

11001,1,5,8

11001,2,5,4

11001,3,15,3 and so on.....

MODEL2:

globals:
    MIG:
        path: emigr_target2.csv
        type: float

entities:   
    Household:

         processes:
            test_chenard:
                - migrant_pool: FALSE
                - base_period: 2015
                - MIG_PERIOD: MIG[:,:,:,period-base_period]###municipality, gender, age,
                - need: MIG_PERIOD
              #  - last_clone_period: if((period == 2014), 0, last_clone_period)
                - num_persons: persons.count()
                - is_candidate: uniform() > 0.5
                - migrant_pool: align_abs(num_persons, need, filter = is_candidate, link= persons,  errors= 'carry')
                - show("migrant pool", sum(migrant_pool * num_persons))

The global MIG looks like :

res_id,age,gender,period

,,,2015,2016

11001,0,1,4,5

11001,1,1,5,8

11001,2,1,5,10

11001,3,1,15,4 and so on....

###

I ran the two models for the first period (2015). The results summarise as follows:

MODEL 1

- 10/12 select_int_emigrants ... - reading C:\liam2\SV\emigr_target.csv

total needed 284123

missing 7344 individuals

migrant pool 276779 done

MODEL 2

- 10/12 test_chenard ... adding 0 individuals from last period error

total needed 284123

missing 76071 individuals

migrant pool 208052 done

Can any one tell me what the difference is in both codes? Or where my mistake might be?

(No random seed was set).

Thanks in advance,

Ingrid

[Gaëtan de Menten]

It might just be a typo in your email, but your two tables do not have the same values. There is some weird thing between the gender and period axes.

 

In MODEL1:

age=0, gender=True =>  4; age=0, gender=False => 5 (in all periods)

age=1, gender=True =>  5; age=1, gender=False => 8 (in all periods)

 

In MODEL2:

age=0, gender=1,period=2015 => 4; age=0, gender=1,period=2016 => 5

age=1, gender=1,period=2015 => 5; age=1, gender=1,period=2016 => 8

 

Hope it helps,

Gaëtan

Disclaimer: This e-mail may contain confidential information which is intended only for the use of the recipient(s) named above.
If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
Please note that e-mail messages cannot be considered as official information from the Federal Planning Bureau.

[Ingrid Schockaert]

Gaetan,

Thanks for your fast reaction, but I don't see the difference.

The alignment file for model 1 only refers to 2015

The part visible for model 2, is only for men.

So men in the file for model 1 should be compared to the numbers for 2015 in file model 2

These are the same.

So I'm sorry, but I don't see the weird thing about the gender and period axes ):

Ingrid

--
You received this message because you are subscribed to a topic in the Google Groups "liam2-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liam2-users/I4YYewzhcrk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to liam2-users+unsubscribe@googlegroups.com.
To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

[Gaëtan de Menten]

> The alignment file for model 1 only refers to 2015

> The part visible for model 2, is only for men.

 

Indeed, but the weird thing is that they are exactly the same numbers even though the two arrays do not refer to the same things. This could be a coincidence, but I don't think it is.

 

Gaëtan

 

--

To unsubscribe from this group and all its topics, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

 

--
You received this message because you are subscribed to the Google Groups "liam2-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

[Ingrid Schockaert]

Dear Gaetan,

The part for men in model1 is equal to the 2015 column in model 2 : that is correct since the numbers in both cases refer to men and the year 2015.

But the other collums are not the same, except for for the first two numbers (5,8): that is BY PURE COINCIDENCE.
I do believe the tables are correct.

So the run for year 2015 of model 2 should give exactly the same result as the run for year 2015 of model 1. Liam reads the same "total needed of 284123" for the two models, but the "missings" are much larger for the second model.

regards,

Ingrid

--

To unsubscribe from this group and all its topics, send an email to liam2-users+unsubscribe@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

--
You received this message because you are subscribed to the Google Groups "liam2-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liam2-users+unsubscribe@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

Disclaimer: This e-mail may contain confidential information which is intended only for the use of the recipient(s) named above.
If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
Please note that e-mail messages cannot be considered as official information from the Federal Planning Bureau.

--

You received this message because you are subscribed to a topic in the Google Groups "liam2-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liam2-users/I4YYewzhcrk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to liam2-users+unsubscribe@googlegroups.com.

[Gaëtan de Menten]

Dear Ingrid,

 

In your original email you said you did not set a random seed. Why is that? To rule out a difference due to random numbers, it would be nice to test both versions with the same seed.

 

Failing that, please create a test case by trim down your simulation as much as you can and send me (not to the mailing list) a test simulation which reproduces the problem.

 

Gaëtan

 

--

To unsubscribe from this group and all its topics, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

 

--

You received this message because you are subscribed to the Google Groups "liam2-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

Disclaimer: This e-mail may contain confidential information which is intended only for the use of the recipient(s) named above.
If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
Please note that e-mail messages cannot be considered as official information from the Federal Planning Bureau.

--
You received this message because you are subscribed to a topic in the Google Groups "liam2-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liam2-users/I4YYewzhcrk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

--
You received this message because you are subscribed to the Google Groups "liam2-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liam2-users...@googlegroups.com.

To post to this group, send email to liam2...@googlegroups.com.
Visit this group at https://groups.google.com/group/liam2-users.

[Gaëtan de Menten]

Dear Ingrid,

 

Sorry for the slow reply. I wanted to actually confirm my intuition before answering you. Also, I am continuing the discussion here because it is potentially interesting for other users to have the conclusion of the story.

 

I can now confirm that you were hit by a nasty assumption on the part of LIAM2. LIAM2 assumes that the multi-dimensional data files are sorted like in memory, that is the first "header" column is varying the slowest, the last column varying fastest (a bit like if you sorted by first column then broke ties by second column then by third column, etc.; except that each column does not actually need to be sorted).

 

I think this is a reasonable requirement because it is a very common way to sort data but I should at least have documented it and made LIAM2 check that is verified. I am sorry that it was the case for neither.

The good news is that this whole class of problems will be fixed in the next release of LIAM2 (0.13). The bad news is that it will probably take months before this release is done.

 

Now for your particular case, this assumption is verified for emig_targets.csv, so this gives sensible results:

>>> load('emigr_targets.csv', int)[:2, :2]

- reading emigr_targets.csv

 

res_id | age | gender |     

       |     |   True | False

11001 |   0 |      4 |     5

11001 |   1 |      5 |     8

11002 |   0 |    150 |   118

11002 |   1 |    241 |   214

 

 

… but not for emigr_targets2.csv, so this gives bad results:

 

>>> load('emigr_targets2.csv', int)[:2, :2]

- reading emigr_targets2.csv

 

res_id | age | gender | period |    

       |     |        |   2015 | 2016

11001 |   0 |   True |      4 |    5

11001 |   0 |  False |      5 |    8

11001 |   1 |   True |      5 |   10

11001 |   1 |  False |     15 |    4

11002 |   0 |   True |      2 |    4

11002 |   0 |  False |      8 |    6

11002 |   1 |   True |      6 |    9

11002 |   1 |  False |      5 |   12

 

It is more obvious that the numbers are wrong when we try to take only the first year (2015):

 

>>> load('emig_targets2.csv', int)[:2, :2, :, 0]

- reading emig_targets2.csv

 

res_id | age | gender |     

       |     |   True | False

11001 |   0 |      4 |     5

11001 |   1 |      5 |    15

11002 |   0 |      2 |     8

11002 |   1 |      6 |     5

 

And here is what I get after sorting columns (I will send you this sorted file via private mail if you are interested), which looks correct to me:

 

>>> load('emig_targets3.csv', int)[:2, :2, :, 0]

- reading emig_targets3.csv

 

res_id | age | gender |     

       |     |   True | False

11001 |   0 |      4 |     5

11001 |   1 |      5 |     8

11002 |   0 |    150 |   118

11002 |   1 |    241 |   214

 

Hope it helps,

Gaëtan