Enrollment Management
(augments Td_2.1)

Higher Education is a computer-based simulation game under development that targets both the institutional professional and the interested layperson to participate in leadership challenges in a college or university setting. Players set, monitor, and modify a variety of institutional parameters and policies, allocate resources as they see fit, and watch as results continually unfold. The game provides an opportunity to experiment and succeed or fail in a safe and entertaining fantasy environment. While Higher Education is necessarily a caricature of real academic life, it is grounded in authentic data and will provide serious lessons in higher education.

The game will be driven by a sophisticated simulation engine, described in Technical Documents 2.1 through 2.5, that models enrollment management, resource allocation and finance, academic operations, physical plant activities, and performance indicators. Several more algorithms deal with the game’s initialization procedures. The present Technical Document is the fourth in the 1998 (3.x) series:

Most of the material described herein is prototyped in the Mathematica file "HE.EnrMgt.rev.nb". This paper is intended to illuminate elements of the prototype, not to provide a free-standing explanation of the algorithms and procedures.

The Mathematica program is organized into three sections. The first provides general functions and data, the second contains the algorithms and procedures pertaining to traditional undergraduates (SL-1), and the third deals with all the other student levels (SL-2 through SL-5). The treatment of traditional undergraduates is much more detailed than that for the other student levels. In some cases, procedures for the other student levels refer to functions or data for traditional undergraduates.

To run the Mathematical prototype first execute "kernel: evaluation:evaluate initialization" from the Mathematica menu line. Test results for many of the individual Mathematica functions have been provided, but these are not recalculated during initialization. (One may wish to close all cells after initialization to avoid screen clutter.) Then open the "Main Procedure: Execution" cell and execute it. Other test results can be obtained as desired.

The game’s enrollment management model should run just before the beginning of each academic year (i.e., before the Fall trimester), just after the resource allocation model.

Applications, admissions, financial aid, and matriculations for traditional undergraduates are simulated for each gender-ethnic group ("geg") and student segment ("seg"). The gegs and segs were defined in Td_2.1. The data structure is illustrated by:

variable[whiteMale] = {list of values for the seven student segments},

and similarly for the other three gegs.

Execution of the Mathematica initialization procedure activates the following. (Items 1 and 2 are located under "General" because they include items related to other student levels.)

1. Player-initiated variables ("Player input"). These should conform to the screens now under development by Enlight.
2. Student preference weights and associated data for the PGI and peer institutions. (These come from the initialization spreadsheets discussed in Td_3.1 and Td_3.3.) The peer institution data are calculated from the assumed PGI-peer ratios for purposes of testing. The peer data should be calculated from the list of institutions determined in the "initialization: peer_insts" spreadsheet using the formulas set out in the "initialization: initial_conds" sheet. This section also sets out assumptions for the latency fractions (l) for applications and yield rates.
3. Admissions data: the initial applications ratios, yield rates, and fractions of initial matriculations—by geg and seg. (From the initialization spreadsheets.) This section also converts the applications ratios into initial values for applications and base applications, and sets up the base yield rates. There is a formula to conform the initial matriculations fractions for gegs to the data on the "initial_conds" spreadsheet.
4. Financial aid data: (a) the means and variances for academic rating, extracurricular rating, athletic rating, and family income— matriculations by geg and seg; (b) the definition of the maximum aid level (maxAid), which equals tuition rate + the room and board rate + $2000; and (c) the initial fraction of students on aid and the average aid level. (All from the initialization spreadsheets.) This section also includes an income update factor to conform the NELS income data to the game’s IPEDS financial data. (Penn should get the right value.)

This section should not be programmed as such. The C-code should access the appropriate data elements from elsewhere in the game.

The applications for year t are obtained as follows for each geg and seg:

(1) applications[t] = l x pref_apps x baseApps x chance + (1– l) applications[t–1]

where pref_apps is the output of the preference function for applications and chance is the result of a "chance-type" event as discussed elsewhere in connection with playability. Chance should be centered around one so that it lifts or erodes baseApps. Chance may apply to an individual geg and/or seg or to all or some of them at Enlight’s discretion. Chance has not been included in the prototype.

Note that baseApps is determined at initialization and doesn’t change during play. We could subject it to an exogenous trend in future version but let’s ignore than refinement for now.

The preference function depends on the current values of institutional characteristics like prestige, etc., the tuition rate just set by the resource allocation algorithm, and prior year’s values of admissions-dependent variables like applications ratio, yield, and percent part-time and financial aid. (The prototype addresses the lag for financial aid but the others.) The preference function has different weights for minorities and non-minorities and for public and private institutions. (See the "Stu_Pref" spreadsheet.) It does not produce different values by student segment.

Admissions are determined by quadratic programming or set equal to the number of applications, depending on whether the PGI is currently "selective" or not. Selectivity occurs when expected total admissions is greater that or equal to the desired total intake—that is, when:

The quadratic program maximizes the PGI’s expected utility subject to certain constraints. Expected utility depends on the player’s admissions priorities and decisions about special treatment for minorities and athletes ("Priorities" screen).

The equations are as follows:

The last constraint is required because, without it, the maximization of total utility would result in the admission of all applicants.

Expected utility sums a linear and a quadratic term for each geg and seg. The linear term is the weighted sum of the player’s admissions priorities times the geg/seg’s mean values for academic rating, extracurricular rating, and athletic rating. The multiplier for athletic special consideration is applied if appropriate. The multiplier is determined from the "high, medium, none" inputs on the "Priorities" screen according to rule given in the "Multipliers" cell under "General Functions".

The quadratic term reflects the fact that the average utility of admissions from each geg/seg combination will decline the deeper one goes into the applicant pool. We assume that the PGI always admits students with the best utility value in a geg/seg cell first. If all the students in the cell were admitted, the utility would simply equal the cell average. Admitting only a portion of the applications will result in a utility greater than the cell average. Hence the expected utility will decline as the number of admitees in a cell increases. In addition to reflecting this theoretical consideration, adding the quadratic term produces a more realistic result than simply using the linear term because the linear model is "all-or-none" except for one cell at the margin. In other words, the linear model would admit all applicants in every cell until the intake constraint is satisfied—the only exception would be the cell which puts intake over the top.

The quadratic term is obtained by approximating a more complex function. The term, which multiplies the admissions numbers, equals 5/(number of applicants in the geg/seg cell). The number "5" was determined according to the "Admissions: tests of k-factor" Mathematica cell. (The theory behind this will be provided later.)

The prototype sets up the code in symbolic terms first, then converts to numerical values in the "Initialize the quadratic program" cell. The game engine should get the numeric values directly. Because our QP procedure minimizes a quadratic program subject to "greater than or equal to" constraints the code multiplies the objective function and applications constraint by –1.

The financial aid rules used to create student sims depends on the qualification limits for need and merit aid, and on Player’s input for the fraction of need aid to be covered. The qualification limits also depend on Player input. The "Initialization of Aid Functions" has been prototyped in Mathematica and needs to be coded into the game engine.

While not used in the game program, the prototype for the expected fraction of students on aid and the expected average aid amount depend on these factors. These models were used in checking the convergence of the financial aid algorithm.

Need aid is initialized to the fraction of students receiving need aid as obtained from initial conditions database. Specifically, the fraction equals the maximum of the fraction of students with need and the fraction with need given need aid (columns DR & DS of init_conds). This somewhat arbitrary formula is designed to mitigate missing data problems while approximating the true fraction of students with need. Initialization uses this procedure :

minimizing (cdf[income, y] – fraction of students with need)^2,

with respect to y. The result equals the maximum income level that qualifies for need aid: nM in the program. Need aid declines proportionally with income until income equals nH – maxAid: labeled nL in the program. In other words, student need equals maxAid until income reached nL, then declines until it reaches zero at nH.

Merit aid is initialized in a similar way. The two differences are as follows. First, the fraction of students on merit aid is input by the Player rather than from the initialization database. This is used to determine mL—the lowest utility score that will qualify for aid. Second, mH is the utility score exceeded by only 2.5% of the overall population. The 2.5% figure is arbitrary. It can be changed during beta testing.

The matriculations figures are obtained from admissions by applying the current yield rates (getMatrics). The yield rates, which can be different for each geg and seg, are obtained from this formula:

(4) yieldRate[t] = l x pref_yield x baseYield x chance + (1– l) yieldRate[t–1]

This is analogous to the formula for applications (equation 1), and the same considerations and definitions apply. Note that different latency factors (l)apply to applications and yields. Another difference is that preference function, pref_yield, should use the current applications ratio, which is computed by taking the ratio of applications (equation 1) to the prior year’s matriculations for the geg and seg (the applications ratio update has not been prototyped).

My current thinking calls for the preference function to use the prior-year’s statistics for the fraction of students on aid and average aid by geg and seg. This is less desirable theoretically than using the expected values for these quantities, which are based on current rather than prior-year information, because admittees respond to actual aid offers. The prototype uses expected values. The expected value calculations have been prototyped and are described in Appendix A.1. It would be desirable to program and use them in the game, but their complexity leads me to hold back on this specification at least for the time being. We may wish to revisit this question later.

Matriculations in each geg/seg cell are calculated by multiplying the yield rates by the figures for admissions. Then the total financial aid requirement for new students is calculated by multiplying the average financial aid per student for each geg and seg by the number of matriculants in the cell and summing over cells.

The number of top athletes equals the number of matriculants in student segment 4 (athlete), summed over gegs. The game interface should make clear that this represents the number of newly recruited top athletes, not the total number currently attending the institution. (The student database doesn’t carry information about whether a sim is a top athlete; this might be added in a future version.)

The applications, admissions, financial aid, and matriculation algorithms should be approximately in equilibrium—that is, mutually consistent—at the start of play. This can be achieved by running the enrollment management procedure several after initialization, before play begins. The latency factors should be set to zero temporarily during this process to speed convergence.

The Mathematica cell labeled "Model Initialization Test" tests convergence using the expected values for fraction of students on aid and average aid described in Appendix A.1. Convergence to within 1.5% was achieved in four iterations.

New sims are created based on the rounded value of matriculations for each geg and seg. Values for academic rating (labeled "talent" in the student database), extracurricular rating, and athletic rating should be obtained by drawing random normal variables with the mean and variance for the geg and seg. Income values should be obtained similarly. These need not be stored in the sim record, but they are needed in the calculation of financial aid.

The financial aid figures for each student sim are obtained by applying the financial aid rules to the income and utility figures for the sim. Need aid is considered first: needAid =

If[ income < nL = fraction of need covered x maxAid ELSE
income < nH = fraction of need covered x maxAid x (nH–income)/(nH–nL)
ELSE = 0]

Merit aid is calculated as a residual after need aid. First calculate utility using the utility function as prototyped. Then, meritAid =

If[ utility > mH = maxAid – needAid ELSE
utility > mL = Max[maxAid x (utility–mL)/(mH–mL) – needAid, 0]
ELSE = 0]

The financial aid rules should be applied to all sims, not just the newly-created ones. However, for returning sims the values of academic, extracurricular, and athletic performance should be used in place of the talent indices. The annual aid recalculation will allow changes in maxAid, which depends on the tuition and residence hall rates, to be reflected in the current level of need aid, and performance changes to be reflected in merit aid. It will also allow annual recalibration to the financial aid budget should this be specified by Player.

The creation of new student sims has not been prototyped.

The final step is to calculate the average talent ratings and total financial aid requirements for entering students by student level and gender-ethnic group, and total financial aid for all students. Average talent rating is obtained by averaging the academic ratings of the newly-created sims. Financial aid requirements are obtained by summing financial aid over student sims. (The same procedures apply to the other student levels.) These summations have not been pototyped. What geg/seg combinations should be averaged or summed will depend on refinement of the player interface.

Enrollment management for the other student levels has been simplified compared to that for traditional undergraduates. First, we want to avoid adding to the game’s complexity. Second, data do not exist to support the level of detail used for traditional undergraduates. The simplifications are fourfold: (1) there is no differentiation by student segment; (2) applications, admissions and matriculations are not simulated separately; (3) only merit aid can be offered to non-traditional undergraduates; and (4) no financial aid is given to masters and professional students or non-matriculated students, and doctoral student are all given aid at the maxAid level.

One type of student preference function, for applications, is defined for each student level (SL-2 through SL-5). The coefficients for these functions are provided in an updated version of the "HE.STU.pref" spreadsheet dated early July, 1998. (The variables are the same as for traditional undergraduates.) As for traditional undergraduates, there are separate coefficient sets for minorities and non-minorities and for public and private institutions. The student preference calculations work as described in Section 2.2 except that the financial aid variables are zeroed out for non-traditional undergraduates if these students are not to be given aid. The preference weights for the other student levels equal zero, since aid isn’t a factor for these students.

The student preference function in the prototype should be modified to use the prior year’s values for frOnAid and aveAid, not the expected values. The expected values need not be calculated.

The simplified model works off initial figures for appsRatio and the mean and variance of academic rating for each student level and gender-ethnic group. These are obtained as follows (the index for student level is understood):

1. appsRatio. Calculate the weighted average, over student segments, of the traditional undergraduate applications ratios using the initial matriculation fractions as weights. Multiply the result by the ratio of student preference function initial output to the initial output of the SL-1 "apps" preference function, squared. (The power may be changed during beta.) This increases or decreases the appsRatios according to the relative satisfaction of the potential students compared to traditional undergraduates. Then add a random normal deviate with mean zero and standard deviation equal to (say) 10% of the previous result. (The random deviate has not been prototyped.)
2. applications. Equals the target intake figure for the student level times the appsRatio.
3. conversionRate. The fraction of applicants who will matriculate if offered admission, this equals 1/appsRatio.
4. mean academic rating. The weighted average, over student segments, of the traditional undergraduate mean academic ratings using the initial matriculation fractions as weights. Then multiply the results by the "non-traditional student multiplier" (for SL-2 only) and again by the square of the relative preferences ratio. Once again, we should add a random normal deviate with mean zero and standard deviation equal to (say) 10% of the previous result. (This has not been prototyped.)
5. variance of academic rating. The weighted average, over student segments, of the variance of academic ratings plus the square of difference between the mean rating just calculated and the SL-1 mean. (This takes account of the within- and between-segment variances.) There is no need for a preference ratio adjustment or a random deviation.
6. financial aid limits: mL2 and mH2 (applies to sL2 only). The lower limit (mL2) equals the value of academic rating that minimizes the squared deviation of cdf from the fraction of non-traditional students offered aid. The upper limit (mH2) equals the academic rating that minimizes the squared deviation of 1–cdf from the 2.5% figure described in the last paragraph of Section 2.4.

The annual enrollment management calculation proceeds as follows for each SL >1 and geg:

1. Calculate applications as in equation (1), using the student preference function weights and latency figure for the student level. The student preference function for sL2 uses financial aid data for the previous year, while that for other student levels have the financial aid variables set to zero.
2. Calculate the number of matriculants as the minimum of the player-generated desired intake and the number of applications. Then update the conversion rate to equal the number of matriculants divided by the number of applications.
3. Calculate the minimum academic rating for matriculating students. The minimum academic rating (minAcadRating) is the value that minimizes the squared deviation between the cdf and the updated conversion rate. (The calculation for average academic rating included in the prototype can be ignored, as this variable will be calculated from the student sims.)

The main procedure, doEnrMgt[sL_], begins by calculating the number of applications based on current student preferences. Then it gets the number of matriculations and updates the conversion rate. The conversion rate, in turn, is used to calculate the minimum and average academic rating. For non-traditional undergraduates, financial aid depends on the minimum academic rating. For the remaining student levels, it equals a constant.

The "Initialize Model" procedure iterates the doEnrMgt procedure with latency = 0 until the conversion rate stabilizes. Test results converged after one iteration for all student levels.

Student sims are created by following a variant of the procedure described in Section 2.7. (This process has not been prototyped.) Because there are no values for extracurricular or athletic rating; academic rating is the only talent rating that needs to be created.

The academic ratings should reflect truncation of the applicant pool due to admissions selectivity. The easiest approach is to draw random normal deviates for academic rating from the whole applicant distribution (i.e., with the raw mean and variance for the student level) and then discard any that fall below minAcadRating.

The financial aid for each student sim is obtained by applying the financial aid rules to each sim. For non-traditional undergraduates, the rule depends on mL2 and mH2 as described in paragraph 6 of Section 3.2. Financial aid for the remaining student levels is set as follows: masters and non-matriculated (sL3 and sL5) = 0; doctoral (sL4) = maxAid.

The financial aid rule should be applied to all sims, not just the newly-created ones. The procedure is the same as described for traditional undergraduates in Section 2.7.

Average academic rating and total financial aid requirements by student level and gender-ethnic group are obtained as described for traditional undergraduates.

Player input includes the query, "Is the financial aid budget enforced?" If "yes," total outlays for financial aid (for all student levels) will be limited to the amounts budgeted. If "no," expenditures will be automatically adjusted to equal the sum of financial aid for all the student sims.

We shall assume that any aid adjustments apply only to returning student sims, not to newly-entering ones. This represents a technical simplification should we decide to base incoming yields on the expected values of the financial aid variables, and it also will simplify interpretation of the enrollment management statistics in light of financial aid policies.

The specific rules are:

1. Budget is not enforced: substitute total financial aid as calculated for all student sims for the current year’s aid in the financial tables. In other words, actual financial aid will deviate from budgeted aid due to variations in applications, admissions decisions, yields, economic factors, and student performance.
2. Budget is enforced: reduce the just-calculated financial aid for each returning sim by the ratio of raw total aid for returning sims to the aid budget minus total aid to newly-entering sims. The dropout rate and student morale calculations will be adjusted to assess a penalty for any such reductions.

The two appendices describe how to calculate the expected values for the fraction of new students getting financial aid and the average aid per new student. The procedures are prototyped under the "Financial Aid" headings in the Mathematica program. However, they will not be needed in the game itself and should not be programmed. The initialization procedures will be needed, however, as described in the text.

The financial aid algorithm calculates the fraction of new students on aid and the average aid per new student, by geg and seg and for the PGI overall. It is executed after admissions and before the matriculations model. The annual calculation will be described first, then the initialization procedure. The need algorithms assume that matriculated students represent a random sample from the applicant pool. This is not consistent with the admission algorithm’s assumption of choosing the best students first (within each geg/seg cell), but it provides a major simplification and, in any case, the "best-first" assumption does not necessarily carry over to student matriculation decisions.

There are two kinds of financial aid: need aid and merit aid. Student need depends on student (or parental) income in relation to the total cost for a traditional undergraduate to attend PGI: that is, tuition rate + room and board rate + $2,000 for incidentals. (The $2,000 figure may be changed during beta.) Cost of attendance represents the maximum aid that will be given under any circumstances (maxAid). The fraction of need provided as aid is a player input.

Merit aid is awarded on the basis of utility value (the weighted sum of academic, extracurricular, and athletic rating), adjusted if necessary for minority or athlete status. If a student qualifies for both need and merit aid (and the fraction of need provided is greater than zero), the need aid will be calculated first. Then merit aid will be provided until the student reaches the lessor of the merit qualification or maxAid.

Students’ values of income and utility are assumed to be distributed according to a gamma density function within each geg/seg cell. The gamma is used as an approximation to the normal because it limits itself to positive values and is easier to compute. The means and standard deviations (which are converted to variances) for income and the three variables that determine utility are provided as initialization data. The variance of utility equals the sum of the variances times the squares of the priority weights. Two gamma-based numeric functions are provided: cdf, or "cumulative distribution function," calculates the fraction of the cell population that lies below a given threshold (z); partExp, or partial expectation function, calculates the probability-weighted sum for all values between a lower threshold and an upper bound (xLo and xHi). Both functions depend on the mean (m) and variance (v) for the geg/seg cell.

CyberCampus simplifies the complicated process of awarding need and merit aid while maintaining its most important characteristics. The model divides the students in each geg/seg cell into "regions", as follows:

1. Need aid: (region 2) students qualifying for the maximum amount of need aid, which equals frNeedCovered x maxAid; (region 1) students getting some need aid but less than the maximum; and (region 0) students with no need. We define nL is the boundary between groups 1 and 2 and nH has the boundary between groups 0 and 1.
2. Merit aid: (region 2) students qualifying for the maximum amount of merit aid, which equals maxAid; (region 1) students qualifying for some merit aid but less than the maximum; and (region 0) students below the cutoff utility for merit aid. We define mL is the boundary between groups 1 and 2 and mH has the boundary between groups 0 and 1.

Combining the above produces nine sub-regions, labeled by {i,j}, where i is the index for need and j is the one for merit. The boundary thresholds are determined by the initialization procedure.

We assume that, in the middle regions, aid is proportional to the distance between the lower and upper bounds. In the case of need aid, for example, the aid for a person with income nL + (2/3) x (nH–nL) would be (1/3) x frNeedCovered x maxAid. (Note that need aid falls off as income increases but that merit aid increases with utility.) This assumption results in the same aid value for all students in region 2, no aid for those in region 0, and a proportionally varying amount of aid for those in region 1.

The basic aid function (getAid) calculates:

1. The fraction of a given cell’s population that falls into each of the three regions for need and merit aid: pr[n,i] and pr[m,j]. For example, pr[n,2] = cdf[inc, nL] and pr[m,2] = 1 – cdf[util,mH].
2. The fraction of population in each of the sub-regions: pr[i,j]. Because we assume the income and utility distributions are independent within geg/seg cells, pr[i,j] = pr[n,i] x pr[m,j]. (This relation is embedded in prototype equations as needed rather than being shown separately.)
3. The average need aid per student in each sub-region: aid[n,i,_]. The notation [i,_] represents "need region i and any merit region." (Recall than need aid is calculated before and does not depend on merit aid.) Specifically:
   aid[n,2,_] = frNeedCovered x maxAid;
   aid[n,1,_] = (frNeedCovered x maxAid)/(nH – nL) x (nH –
   partExp[inc,nL,nH]/pr[n,1]); and
   aid[n,0,_] = 0.
   Dividing the last term of aid[n,1,_] by pr[n,1] converts the weighted sum represented by partExp to average aid per student; aid.
4. The average merit aid per student. For example,:
   aid[m,i,2] = maxAid – aid[n,i]; and
   aid[m,i,0] = 0
   (aid[n,i] is written aid[n,i,x] in the Mathematica code—x could be anything), which illustrates the fact that merit aid commences after the need calculation and is limited by maxAid.
   The formula for aid[m,1,1] is more complicate because the aid levels for need and merit are varying simultaneously. The function getMeritAidTemp performs the following calculation:
   • divide the sub-region into slices based on income;
   • calculate the fraction of the population in the slice: prNeedTmp;
   • calculate average need aid for the slice: needAidTmp;
   • apply the formula
   meritAidTmp = (prNeedTmp/pr[n,1])*(maxAid/(mH-mL))*
   (partExp[util,geg,mLtmp,mH] /prMeritTmp- mL),
   where mLtmp = mL + (needAidTmp/maxAid)*(mH-mL);
   • accumulate meritAidTmp over the slices.
   This procedure gets the average merit aid in excess of the need aid for the slice, up to maxAid. The variable mLtmp represents the threshold level of merit aid given the level of need aid.
5. Calculate overall statistics for the geg/seg cell:
   fraction of students on aid = 1 – pr[n,0] x pr[m,0];
   fraction on need aid = pr[n,1] + pr[n,2];
   fraction on merit aid = pr[m,1] + pr[m,2];
   aid per student: sum over i and j of (aid[n,i,j] + aid[m,i,j]) x pr[i,j].

If the player calls for special aid for athletes, this is accommodated by setting average need aid and merit aid for Segment 4 (athlete) to zero and substituting "athletic aid" equal to:

maxAid, if the special parameter equals "high", or
Max[original need aid + merit aid, 0.75 maxAid], if it equals "medium."

The fraction of students on aid is set to one in either case. (Athletic aid has not been prototyped.)

The overall aid statistics by geg and seg might be used to calculate the yield rates during the determination of matriculant numbers. This would provide immediate feedback to Player regarding the effects of changes in financial aid policies. However, the complexity of the expected value calculations has led me to hold off on making the specification at least for the time being. It would be helpful if Enlight would assess the difficulty of implementing these algorithms.

For non-traditional undergraduates (SL-2), if they are offered aid, calculate the percent of students on merit aid and the average merit aid per student using a variation on the procedures for pr[m,j] and aid[m,j] described in Section 2.4. The procedure depends on minAcadRating. If minAcadRating is greater than mH2, then all non-traditional undergraduates receive maxAid. If minAcadRating is between mL2 and mH2, then the formula for meritAidTmp in paragraph 4 of the procedure in Section 2.4 applies, with minAcadRating as the lower limit. The fraction on aid equals 1-cdf[minAcadRating] in this case. If minAcadRating is less than mL2, average aid is the weighted sum of the above two calculations with minAcadRating replaced by mL2 and weights equal to 1–cdf[mH2] and cdf[mH2]–cdf[mL2], respectively.

Financial aid for the remaining student levels is set as follows: masters and non-matriculated (sL3 and sL5) = 0; doctoral (sL4) = maxAid.