Hana,
Thanks, this description explains much of what we were wondering about.
Could you explain the theoretical choices that have lead you to not be
concerned about jobs in particular sectors exceeding capacity?
Thanks,
Brian
On May 13, 2008, at 2:07 PM, Hana Sevcikova wrote:
> Brian,
>
> The DUJM is mainly meant to place jobs of the first category that I
> described below. These should be jobs about which we are not
> concerned if the capacity is exceeded. This is the case of the
> Eugene example. In order to determine these jobs, we simply take all
> unplaced jobs after running the ELCM. This opens a leak for jobs of
> the second category to be also processed by the DUJM. Our reasoning
> is that if the system is working properly there shouldn't be any
> such jobs, or very little, which we can ignore.
>
> If you cover all jobs by specifications and you don't like this
> behavior described above, you could switch the DUJM off. Then jobs
> that could not be placed will be carried unplaced into future years
> and get new chance to be placed there. If you experience a large
> amount of unplaced jobs, then you should revise your capacity and
> development constraints.
>
> Hana
>
>
> Brian Miles wrote:
>> Hana,
>> We currently place all commercial jobs via ELCM. So for us, DUJM
>> is only placing jobs that ELCM fails to place for lack of capacity.
>> What we don't understand is why DUJM is allowed to place jobs in
>> gridcells with zero vacant commercial job space.
>> If zero/negative vacant job space does not trigger development in a
>> gridcell, is there a theoretical reason for the behavior that we're
>> seeing in our model and in the Eugene example?
>> Thanks,
>> Brian
>> On May 6, 2008, at 5:39 PM, Hana Sevcikova wrote:
>>> Brian,
>>>
>>> There are two kinds of jobs placed by the Distribute Unplaced Jobs
>>> Model:
>>>
>>> 1. Those that are not covered by the specification. For example in
>>> the Eugene model, the specification for commercial ELCM contains
>>> submodels (i.e. sectors) 1-8. Commercial jobs of the remaining
>>> sectors (i.e. 9-16) are handled by the DUJ model. Analogous
>>> applies to the industrial jobs.
>>>
>>> 2. Jobs that were not placed via the ELCM due to capacity
>>> restrictions. You should get an idea about the numbers by
>>> inspecting the log file (in the ELCM section you should see
>>> something like 'Number of unplaced jobs: xx (in 3 iterations)',
>>> one such line per submodel).
>>>
>>> I suspect that the majority of jobs handled by the DUJ model
>>> belongs to the first category. If it's a lot or not then depends
>>> on your preferences, how the job placing should be done.
>>>
>>> The answer to your last question is no. The developer model only
>>> builds sqft if that gridcell was selected for building a project.
>>>
>>> Hana
>>>
>>>
>>> Brian Miles wrote:
>>>> Hi Liming,
>>>> I made a mistake. I wanted an indicator that would show me
>>>> vacant commercial units by gridcell, especially those gridcells
>>>> that had negative vacancies. To do this, I modified the
>>>> function opus_core.misc::clip_to_zero_if_needed so that it would
>>>> not clip to zero.
>>>> After computing the indicator, but before running the Eugene
>>>> model and our own model, I forgot to revert clip_to_zero to its
>>>> correct behavior.
>>>> Your answer was correct. I was the culprit. Sorry for the
>>>> confusion.
>>>> Now for a legitimate question. In our model, as well as in the
>>>> Eugene model, we're seeing what seems to be a high number of
>>>> unplaced jobs being placed by the Distribute Unplaced Jobs
>>>> Model. Put more concretely, in both models, there are roughly
>>>> 75,000 total jobs in the base year, and we're seeing on the
>>>> order of 3,000 to 4,000 unplaced jobs at times throughout the
>>>> simulation.
>>>> My question is, is this "normal"? Is there an accepted threshold
>>>> for a reasonable number of jobs that cannot be placed by ELCM?
>>>> Also, in our model, we're seeing an accumulation of negative job
>>>> space vacancy as time progresses. Does the developer model try
>>>> to develop more job space, by building non-residential square
>>>> footage, in areas that currently have negative job space?
>>>> Thanks,
>>>> Brian
>>>> On May 2, 2008, at 3:23 PM, Liming Wang wrote:
>>>>> Brian,
>>>>> This means the array used as weight in the weighted sampling
>>>>> contains
>>>>> negative (less than 0) values. In most case, the weight array
>>>>> is from
>>>>> vacant units attribute, which could contain negative values if
>>>>> more
>>>>> households are allocated to gridcells/buildings than their
>>>>> existing
>>>>> units in the baseyear. In which model do you encounter these
>>>>> warnings?
>>>>>
>>>>> I tried to run eugene sample project for both estimation and
>>>>> simulation, and I didn't seem to get any of similar warnings.
>>>>>
>>>>> Liming.
>>>>>
>>>>> On Fri, May 2, 2008 at 11:07 AM, Brian Miles
>>>>> <Brian.Miles_at_uvm.edu> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> After recently upgrading to the latest development version of
>>>>>> OPUS, I
>>>>>> noticed the following messages that appear when our location
>>>>>> choice
>>>>>> models run:
>>>>>>
>>>>>> WARNING: Problem with sampling alternatives.
>>>>>> some values of rows [ 929 1797 2590 3657
>>>>>> 3757 5265 7923 10166 12310] in weight_array are less than 0
>>>>>>
>>>>>> The locations differ across models, and sometimes there are
>>>>>> hundreds
>>>>>> reported in the message.
>>>>>>
>>>>>> I thought this was a strange message, so I decided to compare the
>>>>>> output of our model to the Eugene example. I found similar
>>>>>> "errors"
>>>>>> in the Eugene model.
>>>>>>
>>>>>> My questions are: 1) what does this message mean; and 2) does it
>>>>>> indicate a problem that needs to be corrected?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users_at_urbansim.org
>>>>>> http://www.urbansim.org/mailman/listinfo/users
>>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users_at_urbansim.org
>>>> http://www.urbansim.org/mailman/listinfo/users
Received on Wed May 14 2008 - 13:03:22 PDT
This archive was generated by hypermail 2.2.0 : Wed May 14 2008 - 13:03:23 PDT