Just out of curiosity: why would there be an explicit constraint on the maximum number of science targets? I would expect that we always want to observe as many as possible.

Of course the number of science targets will be limited by other factors (e.g. the need to allocate a certain number of fibers to sky and calibration targets). But this should be handled automatically by the software.

The original motivation of this idea is like this:

The galaxy evolution group will do a random sampling for some classes. For example,  imagine that we have 10000 gals for class A (short exposure) and 10000 gals for class B (long exposure) in the catalog, and we want to sample from them with a sampling rate of 50% for class A and 70% for class B. Previously, we pre-selected from the catalog (5000 for class A and 7000 for class B) and feed to the ETS. But, we thought that we might have better optimizations if we feed all galaxies and set the maximum cap corresponding to the sampling rate than previous way, because we get more new networks (5000+7000 vs. 10000+10000) and positional (and collisional) constraint will be relaxed. 

I know this is a bit complicated because the exposure time of each class is different, but I feel that the more networks give us a chance of the better solution. What do you think?

This sounds like a situation where one wants to add problem-specific terms to the cost function, which I'm currently trying to implement. The idea is that the `netflow` module simply builds the basic optimization problem for you and then returns a "problem object", which you can query for individual variables and constraints. In the situation above you could probably add a term to the cost function which becomes large if any sampling rate is too low.

This is still work in progress, but I hope it won't take too long to implement this.

I have now also added a simple way of setting the maximum number of targets to be observed in a given target class. The code is on branch "tickets/FIBERALLOC-11" in the Github repository. The number of targets can be limited by setting the key "nobs_max" to the desired valued in the respective "classdict" entry.

Merged to master.

I'm too stupid for JIRA ... how can I close this?