001/* ---------------------------------------------------------------------------- 002 * This file was automatically generated by SWIG (http://www.swig.org). 003 * Version 3.0.10 004 * 005 * Do not make changes to this file unless you know what you are doing--modify 006 * the SWIG interface file instead. 007 * ----------------------------------------------------------------------------- */ 008 009package org.sbml.libsbml; 010 011/** 012 * <span class="pkg-marker pkg-color-fbc"><a href="group__fbc.html">fbc</a></span> 013 An objective function for a flux. 014 <p> 015 * An integral component in a complete description of a steady-state model is 016 * the so-called <em>objective function</em>, which generally consists of a 017 * linear combination of model variables (fluxes) and a sense (direction). In 018 * the SBML Level 3 <a href='../../../extensions-summary.html#fbc'>Flux Balance Constraints</a> (“fbc”) package, this concept 019 * is succinctly captured in the {@link Objective} class. An {@link Objective} object 020 * includes a list of flux objectives, each in the form of a {@link FluxObjective} 021 * object. 022<p> 023 * The {@link FluxObjective} class is a relatively simple container for a model 024 * variable weighted by a signed linear coefficient. In addition to the 025 * common SBML object attributes of 'id' and 'name' (both of which are 026 * optional), it adds two required attributes: 'reaction' and 'coefficient'. 027 <p> 028 * The 'reaction' attribute must have a value of type <code>SIdRef</code>, 029 * and its value is restricted to the identifier of a {@link Reaction} object in the 030 * model. The 'reaction' attribute identifiers the reaction to which the 031 * {@link FluxObjective} applies. The 'coefficient' attribute must have a value of 032 * type <code>double</code>, and refers to the coefficient that this 033 * {@link FluxObjective} takes in the enclosing {@link Objective}. Its unit of measurement 034 * is <code>dimensionless</code>. The meaning of these two attributes 035 * together is given by the formula <em>coefficient × 036 * reaction-flux</em>. Since reactions in SBML Level 3 are in units of 037 * <em>extent</em>, the units of a flux objective are thus <em>extent per 038 * time</em>. 039 <p> 040 * The following example * illustrates the use of these attributes in an 041 * example of a * ListOfObjectives: 042 * <pre class='fragment'> 043<fbc:listOfObjectives fbc:activeObjective='obj1'> 044 <fbc:objective fbc:id='obj1' fbc:type='maximize'> 045 <fbc:listOfFluxObjectives> 046 <fbc:fluxObjective fbc:reaction='R1' fbc:coefficient='1'/> 047 <fbc:fluxObjective fbc:reaction='R2' fbc:coefficient='2'/> 048 </fbc:listOfFluxObjectives> 049 </fbc:objective> 050</fbc:listOfObjectives> 051</pre> 052 <p> 053 * @see Objective 054 * @see ListOfObjectives 055 * @see ListOfFluxObjectives 056 */ 057 058public class FluxObjective extends SBase { 059 private long swigCPtr; 060 061 protected FluxObjective(long cPtr, boolean cMemoryOwn) 062 { 063 super(libsbmlJNI.FluxObjective_SWIGUpcast(cPtr), cMemoryOwn); 064 swigCPtr = cPtr; 065 } 066 067 protected static long getCPtr(FluxObjective obj) 068 { 069 return (obj == null) ? 0 : obj.swigCPtr; 070 } 071 072 protected static long getCPtrAndDisown (FluxObjective obj) 073 { 074 long ptr = 0; 075 076 if (obj != null) 077 { 078 ptr = obj.swigCPtr; 079 obj.swigCMemOwn = false; 080 } 081 082 return ptr; 083 } 084 085 protected void finalize() { 086 delete(); 087 } 088 089 public synchronized void delete() { 090 if (swigCPtr != 0) { 091 if (swigCMemOwn) { 092 swigCMemOwn = false; 093 libsbmlJNI.delete_FluxObjective(swigCPtr); 094 } 095 swigCPtr = 0; 096 } 097 super.delete(); 098 } 099 100 101/** 102 * Creates a new {@link FluxObjective} with the given SBML Level, Version, and 103 * “fbc”package version. 104 <p> 105 * @param level a long integer, the SBML Level to assign to this 106 * {@link FluxObjective}. 107 <p> 108 * @param version a long integer, the SBML Version to assign to this 109 * {@link FluxObjective}. 110 <p> 111 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 112 * this {@link FluxObjective}. 113 <p> 114 * <p> 115 * @note Attempting to add an object to an {@link SBMLDocument} having a different 116 * combination of SBML Level, Version and XML namespaces than the object 117 * itself will result in an error at the time a caller attempts to make the 118 * addition. A parent object must have compatible Level, Version and XML 119 * namespaces. (Strictly speaking, a parent may also have more XML 120 * namespaces than a child, but the reverse is not permitted.) The 121 * restriction is necessary to ensure that an SBML model has a consistent 122 * overall structure. This requires callers to manage their objects 123 * carefully, but the benefit is increased flexibility in how models can be 124 * created by permitting callers to create objects bottom-up if desired. In 125 * situations where objects are not yet attached to parents (e.g., 126 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 127 * libSBML determine such things as whether it is valid to assign a 128 * particular value to an attribute. For packages, this means that the 129 * parent object to which this package element is being added must have 130 * been created with the package namespace, or that the package namespace 131 * was added to it, even if that parent is not a package object itself. 132 */ public 133 FluxObjective(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException { 134 this(libsbmlJNI.new_FluxObjective__SWIG_0(level, version, pkgVersion), true); 135 } 136 137 138/** 139 * Creates a new {@link FluxObjective} with the given SBML Level, Version, and 140 * “fbc”package version. 141 <p> 142 * @param level a long integer, the SBML Level to assign to this 143 * {@link FluxObjective}. 144 <p> 145 * @param version a long integer, the SBML Version to assign to this 146 * {@link FluxObjective}. 147 <p> 148 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 149 * this {@link FluxObjective}. 150 <p> 151 * <p> 152 * @note Attempting to add an object to an {@link SBMLDocument} having a different 153 * combination of SBML Level, Version and XML namespaces than the object 154 * itself will result in an error at the time a caller attempts to make the 155 * addition. A parent object must have compatible Level, Version and XML 156 * namespaces. (Strictly speaking, a parent may also have more XML 157 * namespaces than a child, but the reverse is not permitted.) The 158 * restriction is necessary to ensure that an SBML model has a consistent 159 * overall structure. This requires callers to manage their objects 160 * carefully, but the benefit is increased flexibility in how models can be 161 * created by permitting callers to create objects bottom-up if desired. In 162 * situations where objects are not yet attached to parents (e.g., 163 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 164 * libSBML determine such things as whether it is valid to assign a 165 * particular value to an attribute. For packages, this means that the 166 * parent object to which this package element is being added must have 167 * been created with the package namespace, or that the package namespace 168 * was added to it, even if that parent is not a package object itself. 169 */ public 170 FluxObjective(long level, long version) throws org.sbml.libsbml.SBMLConstructorException { 171 this(libsbmlJNI.new_FluxObjective__SWIG_1(level, version), true); 172 } 173 174 175/** 176 * Creates a new {@link FluxObjective} with the given SBML Level, Version, and 177 * “fbc”package version. 178 <p> 179 * @param level a long integer, the SBML Level to assign to this 180 * {@link FluxObjective}. 181 <p> 182 * @param version a long integer, the SBML Version to assign to this 183 * {@link FluxObjective}. 184 <p> 185 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 186 * this {@link FluxObjective}. 187 <p> 188 * <p> 189 * @note Attempting to add an object to an {@link SBMLDocument} having a different 190 * combination of SBML Level, Version and XML namespaces than the object 191 * itself will result in an error at the time a caller attempts to make the 192 * addition. A parent object must have compatible Level, Version and XML 193 * namespaces. (Strictly speaking, a parent may also have more XML 194 * namespaces than a child, but the reverse is not permitted.) The 195 * restriction is necessary to ensure that an SBML model has a consistent 196 * overall structure. This requires callers to manage their objects 197 * carefully, but the benefit is increased flexibility in how models can be 198 * created by permitting callers to create objects bottom-up if desired. In 199 * situations where objects are not yet attached to parents (e.g., 200 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 201 * libSBML determine such things as whether it is valid to assign a 202 * particular value to an attribute. For packages, this means that the 203 * parent object to which this package element is being added must have 204 * been created with the package namespace, or that the package namespace 205 * was added to it, even if that parent is not a package object itself. 206 */ public 207 FluxObjective(long level) throws org.sbml.libsbml.SBMLConstructorException { 208 this(libsbmlJNI.new_FluxObjective__SWIG_2(level), true); 209 } 210 211 212/** 213 * Creates a new {@link FluxObjective} with the given SBML Level, Version, and 214 * “fbc”package version. 215 <p> 216 * @param level a long integer, the SBML Level to assign to this 217 * {@link FluxObjective}. 218 <p> 219 * @param version a long integer, the SBML Version to assign to this 220 * {@link FluxObjective}. 221 <p> 222 * @param pkgVersion a long integer, the SBML Fbc Version to assign to 223 * this {@link FluxObjective}. 224 <p> 225 * <p> 226 * @note Attempting to add an object to an {@link SBMLDocument} having a different 227 * combination of SBML Level, Version and XML namespaces than the object 228 * itself will result in an error at the time a caller attempts to make the 229 * addition. A parent object must have compatible Level, Version and XML 230 * namespaces. (Strictly speaking, a parent may also have more XML 231 * namespaces than a child, but the reverse is not permitted.) The 232 * restriction is necessary to ensure that an SBML model has a consistent 233 * overall structure. This requires callers to manage their objects 234 * carefully, but the benefit is increased flexibility in how models can be 235 * created by permitting callers to create objects bottom-up if desired. In 236 * situations where objects are not yet attached to parents (e.g., 237 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 238 * libSBML determine such things as whether it is valid to assign a 239 * particular value to an attribute. For packages, this means that the 240 * parent object to which this package element is being added must have 241 * been created with the package namespace, or that the package namespace 242 * was added to it, even if that parent is not a package object itself. 243 */ public 244 FluxObjective() throws org.sbml.libsbml.SBMLConstructorException { 245 this(libsbmlJNI.new_FluxObjective__SWIG_3(), true); 246 } 247 248 249/** 250 * Creates a new {@link FluxObjective} with the given {@link FbcPkgNamespaces} object. 251 <p> 252 * <p> 253 * The package namespaces object used in this constructor is derived from a 254 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces 255 * information. It is used to communicate the SBML Level, Version, and 256 * package version and name information used in addition to SBML Level 3 Core. A 257 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an 258 * package namespace object somewhere in a program once, then hand that object 259 * as needed to object constructors of that package that accept it as and 260 * argument, such as this one. 261 <p> 262 * @param fbcns the {@link FbcPkgNamespaces} object. 263 <p> 264 * <p> 265 * @note Attempting to add an object to an {@link SBMLDocument} having a different 266 * combination of SBML Level, Version and XML namespaces than the object 267 * itself will result in an error at the time a caller attempts to make the 268 * addition. A parent object must have compatible Level, Version and XML 269 * namespaces. (Strictly speaking, a parent may also have more XML 270 * namespaces than a child, but the reverse is not permitted.) The 271 * restriction is necessary to ensure that an SBML model has a consistent 272 * overall structure. This requires callers to manage their objects 273 * carefully, but the benefit is increased flexibility in how models can be 274 * created by permitting callers to create objects bottom-up if desired. In 275 * situations where objects are not yet attached to parents (e.g., 276 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 277 * libSBML determine such things as whether it is valid to assign a 278 * particular value to an attribute. For packages, this means that the 279 * parent object to which this package element is being added must have 280 * been created with the package namespace, or that the package namespace 281 * was added to it, even if that parent is not a package object itself. 282 */ public 283 FluxObjective(FbcPkgNamespaces fbcns) throws org.sbml.libsbml.SBMLConstructorException { 284 this(libsbmlJNI.new_FluxObjective__SWIG_4(FbcPkgNamespaces.getCPtr(fbcns), fbcns), true); 285 } 286 287 288/** 289 * Copy constructor for {@link FluxObjective}. 290 <p> 291 * @param orig the {@link FluxObjective} instance to copy. 292 */ public 293 FluxObjective(FluxObjective orig) throws org.sbml.libsbml.SBMLConstructorException { 294 this(libsbmlJNI.new_FluxObjective__SWIG_5(FluxObjective.getCPtr(orig), orig), true); 295 } 296 297 298/** 299 * Creates and returns a deep copy of this {@link FluxObjective} object. 300 <p> 301 * @return a (deep) copy of this {@link FluxObjective} object. 302 */ public 303 FluxObjective cloneObject() { 304 long cPtr = libsbmlJNI.FluxObjective_cloneObject(swigCPtr, this); 305 return (cPtr == 0) ? null : new FluxObjective(cPtr, true); 306 } 307 308 309/** 310 * Returns the value of the 'id' attribute of this {@link FluxObjective}. 311 <p> 312 * @note Because of the inconsistent behavior of this function with 313 * respect to assignments and rules, it is now recommended to 314 * use the getIdAttribute() function instead. 315 <p> 316 * <p> 317 * The identifier given by an object's 'id' attribute value 318 * is used to identify the object within the SBML model definition. 319 * Other objects can refer to the component using this identifier. The 320 * data type of 'id' is always <code>SId</code> or a type derived 321 * from that, such as <code>UnitSId</code>, depending on the object in 322 * question. All data types are defined as follows: 323 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 324 * letter .= 'a'..'z','A'..'Z' 325 * digit .= '0'..'9' 326 * idChar .= letter | digit | '_' 327 * SId .= ( letter | '_' ) idChar* 328 * </pre> 329 <p> 330 * The characters <code>(</code> and <code>)</code> are used for grouping, the 331 * character <code>*</code> 'zero or more times', and the character 332 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 333 * determined by an exact character sequence match; i.e., comparisons must be 334 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 335 * <code>SIdRef</code>, and derived types. 336 <p> 337 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 338 * moved to {@link SBase} directly, instead of being defined individually for many 339 * (but not all) objects. Libsbml has for a long time provided functions 340 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 341 * would fail or otherwise return empty strings if executed on any object 342 * for which those attributes were not defined. Now that all {@link SBase} objects 343 * define those attributes, those functions now succeed for any object with 344 * the appropriate level and version. 345 <p> 346 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 347 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 348 * functions (though not the setId() or unsetId() functions) would instead 349 * reference the value of the 'variable' attribute (for the rules and event 350 * assignments) or the 'symbol' attribute (for initial assignments). 351 * The {@link AlgebraicRule} fell into this category as well, though because it 352 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 353 * always return an empty string, and isSetId() would always return <code>false.</code> 354 * For this reason, four new functions are now provided 355 * (getIdAttribute(), setIdAttribute(String), 356 * isSetIdAttribute(), and unsetIdAttribute()) that will always 357 * act on the actual 'id' attribute, regardless of the object's type. The 358 * new functions should be used instead of the old ones unless the old behavior 359 * is somehow necessary. 360 <p> 361 * Regardless of the level and version of the SBML, these functions allow 362 * client applications to use more generalized code in some situations 363 * (for instance, when manipulating objects that are all known to have 364 * identifiers). If the object in question does not posess an 'id' attribute 365 * according to the SBML specification for the Level and Version in use, 366 * libSBML will not allow the identifier to be set, nor will it read or 367 * write 'id' attributes for those objects. 368 <p> 369 * @return the id of this {@link FluxObjective}. 370 <p> 371 * @see #getIdAttribute() 372 * @see #setIdAttribute(String sid) 373 * @see #isSetIdAttribute() 374 * @see #unsetIdAttribute() 375 */ public 376 String getId() { 377 return libsbmlJNI.FluxObjective_getId(swigCPtr, this); 378 } 379 380 381/** 382 * Returns the value of the 'name' attribute of this {@link FluxObjective} object. 383 <p> 384 * <p> 385 * <p> 386 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 387 * moved to {@link SBase} directly, instead of being defined individually for many 388 * (but not all) objects. Libsbml has for a long time provided functions 389 * defined on {@link SBase} itself to get, set, and unset those attributes, which 390 * would fail or otherwise return empty strings if executed on any object 391 * for which those attributes were not defined. Now that all {@link SBase} objects 392 * define those attributes, those functions now succeed for any object with 393 * the appropriate level and version. 394 <p> 395 * The 'name' attribute is 396 * optional and is not intended to be used for cross-referencing purposes 397 * within a model. Its purpose instead is to provide a human-readable 398 * label for the component. The data type of 'name' is the type 399 * <code>string</code> defined in XML Schema. SBML imposes no 400 * restrictions as to the content of 'name' attributes beyond those 401 * restrictions defined by the <code>string</code> type in XML Schema. 402 <p> 403 * The recommended practice for handling 'name' is as follows. If a 404 * software tool has the capability for displaying the content of 'name' 405 * attributes, it should display this content to the user as a 406 * component's label instead of the component's 'id'. If the user 407 * interface does not have this capability (e.g., because it cannot 408 * display or use special characters in symbol names), or if the 'name' 409 * attribute is missing on a given component, then the user interface 410 * should display the value of the 'id' attribute instead. (Script 411 * language interpreters are especially likely to display 'id' instead of 412 * 'name'.) 413 <p> 414 * As a consequence of the above, authors of systems that automatically 415 * generate the values of 'id' attributes should be aware some systems 416 * may display the 'id''s to the user. Authors therefore may wish to 417 * take some care to have their software create 'id' values that are: (a) 418 * reasonably easy for humans to type and read; and (b) likely to be 419 * meaningful, for example by making the 'id' attribute be an abbreviated 420 * form of the name attribute value. 421 <p> 422 * An additional point worth mentioning is although there are 423 * restrictions on the uniqueness of 'id' values, there are no 424 * restrictions on the uniqueness of 'name' values in a model. This 425 * allows software applications leeway in assigning component identifiers. 426 <p> 427 * Regardless of the level and version of the SBML, these functions allow 428 * client applications to use more generalized code in some situations 429 * (for instance, when manipulating objects that are all known to have 430 * names). If the object in question does not posess a 'name' attribute 431 * according to the SBML specification for the Level and Version in use, 432 * libSBML will not allow the name to be set, nor will it read or 433 * write 'name' attributes for those objects. 434 <p> 435 * @return the name of this SBML object, or the empty string if not set or unsettable. 436 <p> 437 * @see #getIdAttribute() 438 * @see #isSetName() 439 * @see #setName(String sid) 440 * @see #unsetName() 441 */ public 442 String getName() { 443 return libsbmlJNI.FluxObjective_getName(swigCPtr, this); 444 } 445 446 447/** 448 * Returns the value of the 'reaction' attribute of this {@link FluxObjective}. 449 <p> 450 * @return the value of the 'reaction' attribute of this {@link FluxObjective} as a 451 * string. 452 */ public 453 String getReaction() { 454 return libsbmlJNI.FluxObjective_getReaction(swigCPtr, this); 455 } 456 457 458/** 459 * Returns the value of the 'coefficient' attribute of this {@link FluxObjective}. 460 <p> 461 * @return the value of the 'coefficient' attribute of this {@link FluxObjective} 462 * as a double. 463 */ public 464 double getCoefficient() { 465 return libsbmlJNI.FluxObjective_getCoefficient(swigCPtr, this); 466 } 467 468 469/** 470 * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'id' attribute is 471 * set. 472 <p> 473 * <p> 474 * @note Because of the inconsistent behavior of this function with 475 * respect to assignments and rules, it is now recommended to 476 * use the isSetIdAttribute() function instead. 477 <p> 478 * <p> 479 * The identifier given by an object's 'id' attribute value 480 * is used to identify the object within the SBML model definition. 481 * Other objects can refer to the component using this identifier. The 482 * data type of 'id' is always <code>SId</code> or a type derived 483 * from that, such as <code>UnitSId</code>, depending on the object in 484 * question. All data types are defined as follows: 485 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 486 * letter .= 'a'..'z','A'..'Z' 487 * digit .= '0'..'9' 488 * idChar .= letter | digit | '_' 489 * SId .= ( letter | '_' ) idChar* 490 * </pre> 491 <p> 492 * The characters <code>(</code> and <code>)</code> are used for grouping, the 493 * character <code>*</code> 'zero or more times', and the character 494 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 495 * determined by an exact character sequence match; i.e., comparisons must be 496 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 497 * <code>SIdRef</code>, and derived types. 498 <p> 499 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 500 * moved to {@link SBase} directly, instead of being defined individually for many 501 * (but not all) objects. Libsbml has for a long time provided functions 502 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 503 * would fail or otherwise return empty strings if executed on any object 504 * for which those attributes were not defined. Now that all {@link SBase} objects 505 * define those attributes, those functions now succeed for any object with 506 * the appropriate level and version. 507 <p> 508 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 509 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 510 * functions (though not the setId() or unsetId() functions) would instead 511 * reference the value of the 'variable' attribute (for the rules and event 512 * assignments) or the 'symbol' attribute (for initial assignments). 513 * The {@link AlgebraicRule} fell into this category as well, though because it 514 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 515 * always return an empty string, and isSetId() would always return <code>false.</code> 516 * For this reason, four new functions are now provided 517 * (getIdAttribute(), setIdAttribute(String), 518 * isSetIdAttribute(), and unsetIdAttribute()) that will always 519 * act on the actual 'id' attribute, regardless of the object's type. The 520 * new functions should be used instead of the old ones unless the old behavior 521 * is somehow necessary. 522 <p> 523 * Regardless of the level and version of the SBML, these functions allow 524 * client applications to use more generalized code in some situations 525 * (for instance, when manipulating objects that are all known to have 526 * identifiers). If the object in question does not posess an 'id' attribute 527 * according to the SBML specification for the Level and Version in use, 528 * libSBML will not allow the identifier to be set, nor will it read or 529 * write 'id' attributes for those objects. 530 <p> 531 * @return <code>true</code> if the 'id' attribute of this SBML object is 532 * set, <code>false</code> otherwise. 533 <p> 534 * @see #getIdAttribute() 535 * @see #setIdAttribute(String sid) 536 * @see #unsetIdAttribute() 537 * @see #isSetIdAttribute() 538 */ public 539 boolean isSetId() { 540 return libsbmlJNI.FluxObjective_isSetId(swigCPtr, this); 541 } 542 543 544/** 545 * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'name' attribute is 546 * set. 547 <p> 548 * <p> 549 * <p> 550 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 551 * moved to {@link SBase} directly, instead of being defined individually for many 552 * (but not all) objects. Libsbml has for a long time provided functions 553 * defined on {@link SBase} itself to get, set, and unset those attributes, which 554 * would fail or otherwise return empty strings if executed on any object 555 * for which those attributes were not defined. Now that all {@link SBase} objects 556 * define those attributes, those functions now succeed for any object with 557 * the appropriate level and version. 558 <p> 559 * The 'name' attribute is 560 * optional and is not intended to be used for cross-referencing purposes 561 * within a model. Its purpose instead is to provide a human-readable 562 * label for the component. The data type of 'name' is the type 563 * <code>string</code> defined in XML Schema. SBML imposes no 564 * restrictions as to the content of 'name' attributes beyond those 565 * restrictions defined by the <code>string</code> type in XML Schema. 566 <p> 567 * The recommended practice for handling 'name' is as follows. If a 568 * software tool has the capability for displaying the content of 'name' 569 * attributes, it should display this content to the user as a 570 * component's label instead of the component's 'id'. If the user 571 * interface does not have this capability (e.g., because it cannot 572 * display or use special characters in symbol names), or if the 'name' 573 * attribute is missing on a given component, then the user interface 574 * should display the value of the 'id' attribute instead. (Script 575 * language interpreters are especially likely to display 'id' instead of 576 * 'name'.) 577 <p> 578 * As a consequence of the above, authors of systems that automatically 579 * generate the values of 'id' attributes should be aware some systems 580 * may display the 'id''s to the user. Authors therefore may wish to 581 * take some care to have their software create 'id' values that are: (a) 582 * reasonably easy for humans to type and read; and (b) likely to be 583 * meaningful, for example by making the 'id' attribute be an abbreviated 584 * form of the name attribute value. 585 <p> 586 * An additional point worth mentioning is although there are 587 * restrictions on the uniqueness of 'id' values, there are no 588 * restrictions on the uniqueness of 'name' values in a model. This 589 * allows software applications leeway in assigning component identifiers. 590 <p> 591 * Regardless of the level and version of the SBML, these functions allow 592 * client applications to use more generalized code in some situations 593 * (for instance, when manipulating objects that are all known to have 594 * names). If the object in question does not posess a 'name' attribute 595 * according to the SBML specification for the Level and Version in use, 596 * libSBML will not allow the name to be set, nor will it read or 597 * write 'name' attributes for those objects. 598 <p> 599 * @return <code>true</code> if the 'name' attribute of this SBML object is 600 * set, <code>false</code> otherwise. 601 <p> 602 * @see #getName() 603 * @see #setName(String sid) 604 * @see #unsetName() 605 */ public 606 boolean isSetName() { 607 return libsbmlJNI.FluxObjective_isSetName(swigCPtr, this); 608 } 609 610 611/** 612 * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'reaction' attribute 613 * is set. 614 <p> 615 * @return <code>true</code> if this {@link FluxObjective}'s 'reaction' attribute has been set, 616 * otherwise <code>false</code> is returned. 617 */ public 618 boolean isSetReaction() { 619 return libsbmlJNI.FluxObjective_isSetReaction(swigCPtr, this); 620 } 621 622 623/** 624 * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'coefficient' 625 * attribute is set. 626 <p> 627 * @return <code>true</code> if this {@link FluxObjective}'s 'coefficient' attribute has been 628 * set, otherwise <code>false</code> is returned. 629 */ public 630 boolean isSetCoefficient() { 631 return libsbmlJNI.FluxObjective_isSetCoefficient(swigCPtr, this); 632 } 633 634 635/** 636 * Sets the value of the 'id' attribute of this {@link FluxObjective}. 637 <p> 638 * <p> 639 * The string <code>sid</code> is copied. 640 <p> 641 * <p> 642 * The identifier given by an object's 'id' attribute value 643 * is used to identify the object within the SBML model definition. 644 * Other objects can refer to the component using this identifier. The 645 * data type of 'id' is always <code>SId</code> or a type derived 646 * from that, such as <code>UnitSId</code>, depending on the object in 647 * question. All data types are defined as follows: 648 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 649 * letter .= 'a'..'z','A'..'Z' 650 * digit .= '0'..'9' 651 * idChar .= letter | digit | '_' 652 * SId .= ( letter | '_' ) idChar* 653 * </pre> 654 <p> 655 * The characters <code>(</code> and <code>)</code> are used for grouping, the 656 * character <code>*</code> 'zero or more times', and the character 657 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 658 * determined by an exact character sequence match; i.e., comparisons must be 659 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 660 * <code>SIdRef</code>, and derived types. 661 <p> 662 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 663 * moved to {@link SBase} directly, instead of being defined individually for many 664 * (but not all) objects. Libsbml has for a long time provided functions 665 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 666 * would fail or otherwise return empty strings if executed on any object 667 * for which those attributes were not defined. Now that all {@link SBase} objects 668 * define those attributes, those functions now succeed for any object with 669 * the appropriate level and version. 670 <p> 671 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 672 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 673 * functions (though not the setId() or unsetId() functions) would instead 674 * reference the value of the 'variable' attribute (for the rules and event 675 * assignments) or the 'symbol' attribute (for initial assignments). 676 * The {@link AlgebraicRule} fell into this category as well, though because it 677 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 678 * always return an empty string, and isSetId() would always return <code>false.</code> 679 * For this reason, four new functions are now provided 680 * (getIdAttribute(), setIdAttribute(String), 681 * isSetIdAttribute(), and unsetIdAttribute()) that will always 682 * act on the actual 'id' attribute, regardless of the object's type. The 683 * new functions should be used instead of the old ones unless the old behavior 684 * is somehow necessary. 685 <p> 686 * Regardless of the level and version of the SBML, these functions allow 687 * client applications to use more generalized code in some situations 688 * (for instance, when manipulating objects that are all known to have 689 * identifiers). If the object in question does not posess an 'id' attribute 690 * according to the SBML specification for the Level and Version in use, 691 * libSBML will not allow the identifier to be set, nor will it read or 692 * write 'id' attributes for those objects. 693 <p> 694 * @param sid the string to use as the identifier of this object. 695 <p> 696 * <p> 697 * @return integer value indicating success/failure of the 698 * function. The possible values 699 * returned by this function are: 700 * <ul> 701 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 702 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 703 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE} 704 * 705 * </ul> <p> 706 * @see #getIdAttribute() 707 * @see #setIdAttribute(String sid) 708 * @see #isSetIdAttribute() 709 * @see #unsetIdAttribute() 710 */ public 711 int setId(String sid) { 712 return libsbmlJNI.FluxObjective_setId(swigCPtr, this, sid); 713 } 714 715 716/** 717 * Sets the value of the 'name' attribute of this {@link FluxObjective}. 718 <p> 719 * <p> 720 * The string in <code>name</code> is copied. 721 <p> 722 * @param name the new name for the SBML object. 723 <p> 724 * <p> 725 * @return integer value indicating success/failure of the 726 * function. The possible values 727 * returned by this function are: 728 * <ul> 729 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 730 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 731 * 732 * </ul> 733 */ public 734 int setName(String name) { 735 return libsbmlJNI.FluxObjective_setName(swigCPtr, this, name); 736 } 737 738 739/** 740 * Sets the value of the 'reaction' attribute of this {@link FluxObjective}. 741 <p> 742 * @param reaction the value of the 'reaction' attribute to be set. 743 <p> 744 * <p> 745 * @return integer value indicating success/failure of the 746 * function. The possible values 747 * returned by this function are: 748 * <ul> 749 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 750 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 751 * </ul> 752 */ public 753 int setReaction(String reaction) { 754 return libsbmlJNI.FluxObjective_setReaction(swigCPtr, this, reaction); 755 } 756 757 758/** 759 * Sets the value of the 'coefficient' attribute of this {@link FluxObjective}. 760 <p> 761 * @param coefficient the value of the 'coefficient' attribute to be set. 762 <p> 763 * <p> 764 * @return integer value indicating success/failure of the 765 * function. The possible values 766 * returned by this function are: 767 * <ul> 768 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 769 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 770 * </ul> 771 */ public 772 int setCoefficient(double coefficient) { 773 return libsbmlJNI.FluxObjective_setCoefficient(swigCPtr, this, coefficient); 774 } 775 776 777/** 778 * Unsets the value of the 'id' attribute of this {@link FluxObjective}. 779 <p> 780 * <p> 781 * <p> 782 * The identifier given by an object's 'id' attribute value 783 * is used to identify the object within the SBML model definition. 784 * Other objects can refer to the component using this identifier. The 785 * data type of 'id' is always <code>SId</code> or a type derived 786 * from that, such as <code>UnitSId</code>, depending on the object in 787 * question. All data types are defined as follows: 788 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 789 * letter .= 'a'..'z','A'..'Z' 790 * digit .= '0'..'9' 791 * idChar .= letter | digit | '_' 792 * SId .= ( letter | '_' ) idChar* 793 * </pre> 794 <p> 795 * The characters <code>(</code> and <code>)</code> are used for grouping, the 796 * character <code>*</code> 'zero or more times', and the character 797 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 798 * determined by an exact character sequence match; i.e., comparisons must be 799 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 800 * <code>SIdRef</code>, and derived types. 801 <p> 802 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 803 * moved to {@link SBase} directly, instead of being defined individually for many 804 * (but not all) objects. Libsbml has for a long time provided functions 805 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 806 * would fail or otherwise return empty strings if executed on any object 807 * for which those attributes were not defined. Now that all {@link SBase} objects 808 * define those attributes, those functions now succeed for any object with 809 * the appropriate level and version. 810 <p> 811 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 812 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 813 * functions (though not the setId() or unsetId() functions) would instead 814 * reference the value of the 'variable' attribute (for the rules and event 815 * assignments) or the 'symbol' attribute (for initial assignments). 816 * The {@link AlgebraicRule} fell into this category as well, though because it 817 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 818 * always return an empty string, and isSetId() would always return <code>false.</code> 819 * For this reason, four new functions are now provided 820 * (getIdAttribute(), setIdAttribute(String), 821 * isSetIdAttribute(), and unsetIdAttribute()) that will always 822 * act on the actual 'id' attribute, regardless of the object's type. The 823 * new functions should be used instead of the old ones unless the old behavior 824 * is somehow necessary. 825 <p> 826 * Regardless of the level and version of the SBML, these functions allow 827 * client applications to use more generalized code in some situations 828 * (for instance, when manipulating objects that are all known to have 829 * identifiers). If the object in question does not posess an 'id' attribute 830 * according to the SBML specification for the Level and Version in use, 831 * libSBML will not allow the identifier to be set, nor will it read or 832 * write 'id' attributes for those objects. 833 <p> 834 * <p> 835 * @return integer value indicating success/failure of the 836 * function. The possible values 837 * returned by this function are: 838 * <ul> 839 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 840 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 841 * 842 * </ul> <p> 843 * @see #getIdAttribute() 844 * @see #setIdAttribute(String sid) 845 * @see #isSetIdAttribute() 846 * @see #unsetIdAttribute() 847 */ public 848 int unsetId() { 849 return libsbmlJNI.FluxObjective_unsetId(swigCPtr, this); 850 } 851 852 853/** 854 * Unsets the value of the 'name' attribute of this {@link FluxObjective}. 855 <p> 856 * <p> 857 * <p> 858 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 859 * moved to {@link SBase} directly, instead of being defined individually for many 860 * (but not all) objects. Libsbml has for a long time provided functions 861 * defined on {@link SBase} itself to get, set, and unset those attributes, which 862 * would fail or otherwise return empty strings if executed on any object 863 * for which those attributes were not defined. Now that all {@link SBase} objects 864 * define those attributes, those functions now succeed for any object with 865 * the appropriate level and version. 866 <p> 867 * The 'name' attribute is 868 * optional and is not intended to be used for cross-referencing purposes 869 * within a model. Its purpose instead is to provide a human-readable 870 * label for the component. The data type of 'name' is the type 871 * <code>string</code> defined in XML Schema. SBML imposes no 872 * restrictions as to the content of 'name' attributes beyond those 873 * restrictions defined by the <code>string</code> type in XML Schema. 874 <p> 875 * The recommended practice for handling 'name' is as follows. If a 876 * software tool has the capability for displaying the content of 'name' 877 * attributes, it should display this content to the user as a 878 * component's label instead of the component's 'id'. If the user 879 * interface does not have this capability (e.g., because it cannot 880 * display or use special characters in symbol names), or if the 'name' 881 * attribute is missing on a given component, then the user interface 882 * should display the value of the 'id' attribute instead. (Script 883 * language interpreters are especially likely to display 'id' instead of 884 * 'name'.) 885 <p> 886 * As a consequence of the above, authors of systems that automatically 887 * generate the values of 'id' attributes should be aware some systems 888 * may display the 'id''s to the user. Authors therefore may wish to 889 * take some care to have their software create 'id' values that are: (a) 890 * reasonably easy for humans to type and read; and (b) likely to be 891 * meaningful, for example by making the 'id' attribute be an abbreviated 892 * form of the name attribute value. 893 <p> 894 * An additional point worth mentioning is although there are 895 * restrictions on the uniqueness of 'id' values, there are no 896 * restrictions on the uniqueness of 'name' values in a model. This 897 * allows software applications leeway in assigning component identifiers. 898 <p> 899 * Regardless of the level and version of the SBML, these functions allow 900 * client applications to use more generalized code in some situations 901 * (for instance, when manipulating objects that are all known to have 902 * names). If the object in question does not posess a 'name' attribute 903 * according to the SBML specification for the Level and Version in use, 904 * libSBML will not allow the name to be set, nor will it read or 905 * write 'name' attributes for those objects. 906 <p> 907 * <p> 908 * @return integer value indicating success/failure of the 909 * function. The possible values 910 * returned by this function are: 911 * <ul> 912 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 913 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 914 * 915 * </ul> <p> 916 * @see #getName() 917 * @see #setName(String sid) 918 * @see #isSetName() 919 */ public 920 int unsetName() { 921 return libsbmlJNI.FluxObjective_unsetName(swigCPtr, this); 922 } 923 924 925/** 926 * Unsets the value of the 'reaction' attribute of this {@link FluxObjective}. 927 <p> 928 * <p> 929 * @return integer value indicating success/failure of the 930 * function. The possible values 931 * returned by this function are: 932 * <ul> 933 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 934 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 935 * </ul> 936 */ public 937 int unsetReaction() { 938 return libsbmlJNI.FluxObjective_unsetReaction(swigCPtr, this); 939 } 940 941 942/** 943 * Unsets the value of the 'coefficient' attribute of this {@link FluxObjective}. 944 <p> 945 * <p> 946 * @return integer value indicating success/failure of the 947 * function. The possible values 948 * returned by this function are: 949 * <ul> 950 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 951 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 952 * </ul> 953 */ public 954 int unsetCoefficient() { 955 return libsbmlJNI.FluxObjective_unsetCoefficient(swigCPtr, this); 956 } 957 958 959/** 960 * <p> 961 * Replaces all uses of a given <code>SIdRef</code> type attribute value with another 962 * value. 963 <p> 964 * <p> 965 * In SBML, object identifiers are of a data type called <code>SId</code>. 966 * In SBML Level 3, an explicit data type called <code>SIdRef</code> was 967 * introduced for attribute values that refer to <code>SId</code> values; in 968 * previous Levels of SBML, this data type did not exist and attributes were 969 * simply described to as 'referring to an identifier', but the effective 970 * data type was the same as <code>SIdRef</code> in Level 3. These and 971 * other methods of libSBML refer to the type <code>SIdRef</code> for all 972 * Levels of SBML, even if the corresponding SBML specification did not 973 * explicitly name the data type. 974 <p> 975 * This method works by looking at all attributes and (if appropriate) 976 * mathematical formulas in MathML content, comparing the referenced 977 * identifiers to the value of <code>oldid</code>. If any matches are found, the 978 * matching values are replaced with <code>newid</code>. The method does <em>not</em> 979 * descend into child elements. 980 <p> 981 * @param oldid the old identifier. 982 * @param newid the new identifier. 983 */ public 984 void renameSIdRefs(String oldid, String newid) { 985 libsbmlJNI.FluxObjective_renameSIdRefs(swigCPtr, this, oldid, newid); 986 } 987 988 989/** 990 * Returns the XML element name of this object. 991 <p> 992 * For {@link FluxObjective}, the XML element name is always <code>'fluxObjective'.</code> 993 <p> 994 * @return the name of this element, i.e. <code>'fluxObjective'.</code> 995 */ public 996 String getElementName() { 997 return libsbmlJNI.FluxObjective_getElementName(swigCPtr, this); 998 } 999 1000 1001/** 1002 * Returns the libSBML type code for this SBML object. 1003 <p> 1004 * <p> 1005 * LibSBML attaches an identifying code to every kind of SBML object. These 1006 * are integer constants known as <em>SBML type codes</em>. The names of all 1007 * the codes begin with the characters <code>SBML_</code>. 1008 * In the Java language interface for libSBML, the 1009 * type codes are defined as static integer constants in the interface class 1010 * {@link libsbmlConstants}. Note that different Level 3 1011 * package plug-ins may use overlapping type codes; to identify the package 1012 * to which a given object belongs, call the <code>getPackageName()</code> 1013 * method on the object. 1014 <p> 1015 * @return the SBML type code for this object: 1016 * {@link libsbmlConstants#SBML_FBC_FLUXOBJECTIVE SBML_FBC_FLUXOBJECTIVE} (default). 1017 <p> 1018 * <p> 1019 * @warning <span class='warning'>The specific integer values of the possible 1020 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 1021 * packages, To fully identify the correct code, <strong>it is necessary to 1022 * invoke both getTypeCode() and getPackageName()</strong>.</span> 1023 <p> 1024 * @see #getElementName() 1025 * @see #getPackageName() 1026 */ public 1027 int getTypeCode() { 1028 return libsbmlJNI.FluxObjective_getTypeCode(swigCPtr, this); 1029 } 1030 1031 1032/** 1033 * Predicate returning <code>true</code> if all the required attributes 1034 * for this {@link FluxObjective} object have been set. 1035 <p> 1036 * @note The required attributes for a {@link FluxObjective} object are: 1037 * <ul> 1038 * <li> 'reaction' 1039 * <li> 'coefficient' 1040 * 1041 * </ul> <p> 1042 * @return a boolean value indicating whether all the required 1043 * attributes for this object have been defined. 1044 */ public 1045 boolean hasRequiredAttributes() { 1046 return libsbmlJNI.FluxObjective_hasRequiredAttributes(swigCPtr, this); 1047 } 1048 1049 1050/** * @internal */ public 1051 void enablePackageInternal(String pkgURI, String pkgPrefix, boolean flag) { 1052 libsbmlJNI.FluxObjective_enablePackageInternal(swigCPtr, this, pkgURI, pkgPrefix, flag); 1053 } 1054 1055}